[CSHARP-2876] Expose the API for creation of implicit client sessions Created: 15/Dec/19  Updated: 27/Oct/23  Resolved: 14/Jan/20

Status: Closed
Project: C# Driver
Component/s: API
Affects Version/s: 2.10.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Roman Kuzmin Assignee: Robert Stam
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related

 Description   

As far as this question at mongodb-user –

https://groups.google.com/forum/#!topic/mongodb-user/c7Do8xYftpg

has no answer, and to my knowledge, C# driver keeps creation of implicit sessions to itself (and uses them effectively).

In my scenarios it would be useful, clean and less error prone to create such sessions in order to avoid numerous code forks on calling driver methods. Namely, I would like to always have a session, either provided by a higher level caller or implicit created when the caller provides none.

In this case, I can always call the driver methods with the session parameter instead of checking the session for null and calling two methods (one depending on the check result).

As far as I can see in the sources, the driver methods without parameters create implicit sessions and call their twin methods with this parameter. In a way, I would like to be able to do this as well, "officially".

Use of MongoClient.StartSession() was my first attempt but it turned out to be only half working. Per this bug report –

https://github.com/nightroman/Mdbc/issues/33

not all servers support this way.

Thus, for the moment I decided to call the internal driver method using reflection. It's a hack indeed but it keeps my code clean and simple.

I hope, one way or another, the driver exposes the API for implicit sessions and the hack goes.



 Comments   
Comment by Roman Kuzmin [ 15/Jan/20 ]

Should I open another issue with suggestion to allow null session parameters, what do you think?

Does it look reasonable or hopeless?

 

I think sooner or later, when people start to use transactions often enough, the current design will show its inconvenience and the issues will be opened anyway. Now, any function with a session parameter has to call every driver function using this inconvenient and error prone pattern `if (session == null) { result = collection.Do(x, y, z); } else { result = collection.Do(session, x, y, z); }`.

 

Comment by Roman Kuzmin [ 14/Jan/20 ]

Let me put it this way. Your suggestion:

> It would probably be better to call the overloads without a session parameter when you don't have a session...

But what is "don't have a session"? It is null versus not null. The driver does not provide any other alternative for this. At the same time it does not allow the session parameter to be null. This leads to some inconveniences in using the API.

Comment by Roman Kuzmin [ 14/Jan/20 ]

Thank you, I understand.

Can you consider alternatives?
For example allow the session parameter to be null? Assuming some internal implicit session or no session, it's up to the driver.

 

Or, for another example, expose another really dummy session type if the approach with null parameter is against some guidelines, style, preferences.

 

 

Comment by Robert Stam [ 14/Jan/20 ]

I understand where you're coming from but I'm concerned about making `StartImplicitSession` public.

Implicit sessions are intended for internal use only. If we were to let implicit sessions leak out of the driver by making `StartImplicitSession` public we would have to worry about applications unintentionally using implicit sessions in ways that are not allowed (like calling `StartTransaction` on an implicit session etc...).

It would probably be better to call the overloads without a session parameter when you don't have a session, though I understand that's a bit tedious. But it should perform slightly better than calling `StartImplicitSession` using reflection and doesn't rely on internal implementation details like implicit sessions.

Generated at Wed Feb 07 21:43:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.