Are Session/Async session's "expensive" to create?
99 views
Skip to first unread message
Justin A
Jun 13, 2016, 4:21:50 AM6/13/16
to RavenDB - 2nd generation document database
Hi all,
just wondering if a Session/Async session are expensive to make. I know the DocStore's are but curious if a session is also (albiet not as much, of course .. but still ..something).
I was thinking about this today when playing around with some simple/common MVC app's where all requests create a session and close it at the end of the request.. which made me think about that vs Lazy<IAsyncSession> (for example).
-le me-
Tal Weiss
Jun 13, 2016, 4:24:36 AM6/13/16
to RavenDB - 2nd generation document database
There creation of the session instance isn't expensive, but you need to keep in mind that you're generating a transaction when saving changes (Accessing the disk).
--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hibernating Rhinos Ltd 
Tal Weiss l Core Team Developer l Mobile:+972-54-802-4849
Office: +972-4-622-7811 l Fax: +972-153-4-622-7811l Skype: talweiss1982
RavenDB paving the way to "Data Made Simple" http://ravendb.net/
Justin A
Jun 13, 2016, 4:33:06 AM6/13/16
to RavenDB - 2nd generation document database
Yeah - it was all the 'state' changes that _could_ occur, that made me wonder if it might be 'nicer' to make it lazy .. so when it's first needed, then it's created.
Once a session is being used, i'm totally kewl with the 'cost' of using it.
half of me is saying: warning! pre-mature optimization.
the other half is saying: be clean with code and only use what u need, when u need it, etc.
urbanhusky
Jun 13, 2016, 5:00:03 AM6/13/16
to RavenDB - 2nd generation document database
Just beware that a session does not track new documents when querying (i.e. you will not find new documents that you've added to your session when querying).
Chris Marisic
Jun 13, 2016, 9:32:06 AM6/13/16
to RavenDB - 2nd generation document database
I strongly advise against the ambient session pattern.
It is the ultimate crux for doing global access in modern software. You have a magic state back channel that is literally the same as using everything global in any language. It only works due to the magic-ness of lifecycle management.
In a well designed system you should not need long lived sessions, you shouldn't need to pass a shared ambient context between multiple "services". If you find yourself needing these crutches this is a giant red flag that your system has both low cohesion and incorrect encapsulation. Ambient state channels are maximal coupling that is invisible. It is next to impossible to test properly due to the intrinsic heart of it being a global side effecting mutable state.
It is the ultimate crux for doing global access in modern software. You have a magic state back channel that is literally the same as using everything global in any language. It only works due to the magic-ness of lifecycle management.
In a well designed system you should not need long lived sessions, you shouldn't need to pass a shared ambient context between multiple "services". If you find yourself needing these crutches this is a giant red flag that your system has both low cohesion and incorrect encapsulation. Ambient state channels are maximal coupling that is invisible. It is next to impossible to test properly due to the intrinsic heart of it being a global side effecting mutable state.
Chris Marisic
Jun 13, 2016, 9:35:08 AM6/13/16
to RavenDB - 2nd generation document database
Lastly, one reason in practice to avoid ambient sessions. Every application i've seen using ambient sessions at some point causes data corruption due to SaveChanges() being called and tracked objects being updated.
No developer should be worrying about whether manipulating locals may actually modify persisted data.
No developer should be worrying about whether manipulating locals may actually modify persisted data.
Felipe Leusin
Jun 15, 2016, 8:37:29 PM6/15/16
to RavenDB - 2nd generation document database
Just to +1 this comment from Chris. Also why in web apps I stopped using InstancePerRequest (or equivalents). The pattern of opening a session in the begining of the request and closing it at the end with automatic savechanges somewhere in the pipeline is great until you enable OptimisticConcurrency (which you should) and everything starts blowing up on your face under heavy load.
Open a session in a controlled state, do it's work. Close it.
urbanhusky
Jun 16, 2016, 1:53:44 AM6/16/16
to RavenDB - 2nd generation document database
...well, there are other patterns that could be used when concurrency and high load start being an issue (i.e. event sourcing)
Justin A
Jun 26, 2016, 8:43:08 PM6/26/16
to RavenDB - 2nd generation document database
Sorry for the late reply ...
but what do you mean by "ambient session's / ambient session pattern" ? My google juice is failing me :(
By this, do you mean a session-per-request (as to my original post)?
If this is what you mean, what is a suggested option then?
Passing in the session instance, to the Service-Method? Creating the session instance in the controller method (only when required, etc).
Oren Eini (Ayende Rahien)
Jun 27, 2016, 8:35:55 AM6/27/16
to ravendb
Session per request, created in the BeforeRequest, closed & SaveChanges in AfterRequest, yes.
I really like this option, personally, but some people seriously dislie it
Hibernating Rhinos Ltd
Oren Eini l CEO l Mobile: + 972-52-548-6969
Office: +972-4-622-7811 l Fax: +972-153-4-622-7811
--
Reply all
Reply to author
Forward
0 new messages