[GODRIVER-2915] hasEnded() Method on Session Created: 18/Jul/23  Updated: 15/Nov/23  Resolved: 15/Nov/23

Status: Closed
Project: Go Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Jonathan Pincas Assignee: Matt Dale
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GODRIVER-3027 Fix and improve causal consistency Go... Backlog

 Description   

It would be really useful for me to be able to test whether a Session has ended.  I see in the Mongo docs there is a Session.hadEnded() method, but it seems like I can't access that method with the Go driver.



 Comments   
Comment by PM Bot [ 15/Nov/23 ]

There hasn't been any recent activity on this ticket, so we're resolving it. Thanks for reaching out! Please feel free to reopen this ticket if you're still experiencing the issue, and add a comment if you're able to provide more information.

Comment by PM Bot [ 07/Nov/23 ]

Hi jon@pakk.io! GODRIVER-2915 is awaiting your response.

If this is still an issue for you, please open Jira to review the latest status and provide your feedback. Thanks!

Comment by Matt Dale [ 31/Oct/23 ]

Hey jon@pakk.io, sorry for the slow reply! In the case you described, a HasEnded method would not be appropriate to use because a mongo.Session is not safe for concurrent use in multiple goroutines. While you can add synchronization on top of a mongo.Session to accomplish something similar, it's still possible to read stale data from MongoDB because of replication delay (if your database is a replica set or sharded cluster). It sounds like what you want is causal consistency between two sessions, which guarantees the 2nd session can see all changes made by the 1st session.

Here's an example of how to use the Go driver to create a 2nd session that is causally consistent with the 1st:

var wg sync.WaitGroup
wg.Add(1)
 
var clusterTime bson.Raw
var opTime *primitive.Timestamp
 
// Start a concurrent goroutine to handle the post-save trigger.
// Use a sync.WaitGroup to wait for the "main" transaction to complete.
go func() {
	wg.Wait()
 
	sess2, _ := client.StartSession(options.Session().SetCausalConsistency(true))
	sess2.AdvanceClusterTime(clusterTime)
	sess2.AdvanceOperationTime(opTime)
 
	mongo.WithSession(ctx, sess2, func(ctx mongo.SessionContext) error {
		// Read and write data for trigger that is guaranteed
		// to see all changes made in sess1.
	})
}()
 
sess1, _ := client.StartSession()
sess1.WithTransaction(ctx, func(ctx mongo.SessionContext) (interface{}, error) {
	// Run the "main" transaction in sess1.
})
 
// Record the latest cluster and operation times for
// the "main" transaction session so they can be
// used to create a causally consistent session for
// the trigger.
clusterTime = sess1.ClusterTime()
opTime = sess1.OperationTime()
 
wg.Done()

Does that work for your use case?

Comment by Jonathan Pincas [ 07/Aug/23 ]

Matt - yeah it's definitely not standard usage.  Its a quirk of a long standing architectural decision in our system to do with triggers that need to run post save but recently there was a need to run one of these triggers concurrently which meant that it needed to wait before the 'main' transaction was complete otherwise it would get stale data.  Not the best architecture I know and in the end the workaround was first to just wait 2 seconds, then to just not run it concurrently.  Honestly, not a big deal now, I realise having access to HasEnded() allows hacky behaviour.  It would have been useful to have but I can live without it now if you feel it encourages 'bad' behaviour.

Comment by Matt Dale [ 04/Aug/23 ]

Hey jon@pakk.io thanks for the suggestion! The typical Session usage pattern is to create a new one every time you need one (making sure to call EndSession when you're done with it). As a result, there's usually not a need to check if a previous session has ended, rather create a new one instead.

Can you give me more info about your use case?

  • What problem are you trying to solve?
  • How would having a Session.HasEnded method make solving the problem easier?
  • Do you currently have a workaround to solve the problem?
Comment by PM Bot [ 18/Jul/23 ]

Hi jon@pakk.io, thank you for reporting this issue! The team will look into it and get back to you soon.

Generated at Thu Feb 08 08:39:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.