http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Set, You mentioned avoiding session state. Just wondering how you usually implement long conversations without using session state? http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment23http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment23Tue, 01 Sep 2009 12:04:21 GMTDaRage, Yes, it probably will. If you care about that, take a look at Merge http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment22http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment22Fri, 14 Aug 2009 21:27:45 GMTAyende, But it will still increment the version number, right? The reason I asked this is that if I wrap the 2 requests in a conversation and keep the original NH session in ASP.NET session, then if the use makes no changes to the entity NH will not update it. so it's kind of we have to use conversations anyway because they're very common just like in this scenario and the session-per-request pattern is not sufficient in most cases. Please correct me if I'm wrong. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment21http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment21Fri, 14 Aug 2009 13:27:00 GMTDaRage, If so, to its original values, with is a no op anyway, so you wouldn't care. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment20http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment20Fri, 14 Aug 2009 00:10:47 GMTAyende, What if the user didn't change anything will the row still be updated? http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment19http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment19Thu, 13 Aug 2009 19:48:48 GMTDaRage, No need to do anything else, just materialize the values from the client (including the version number that the user editted) and call Update on it. That would cause NH to update the row, and we use the version number to ensure concurrency control http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment18http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment18Thu, 13 Aug 2009 19:31:58 GMT@Ayende can you explain more? how does NH know if the entity has changed? does it fetch from the db and compare record by record and update if something has changed? are you suggesting to increment the version number manually? isn't the version number number manipulated internally by NH? please explain more. Thanks. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment17http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment17Thu, 13 Aug 2009 19:23:27 GMTI'm with you Tyler. Keep it simple. My head hurts from all the mental gymnastics being discussed. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment16http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment16Thu, 13 Aug 2009 19:07:41 GMTRafal & Kelly, Yes, NH support serialization of the session. Kelly, Wait for it, really wait for it. Set, SqlTransaction inside ASP.Net Sessions. You make me want to cry again. DaRage, You use versioning, and just update the instance. NH takes care of everything else. vbedegi, It seems like if you can't use session per conversation, you can just keep the state on the client, no need to do applications of diffs. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment15http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment15Thu, 13 Aug 2009 18:48:56 GMTNeil, If that is the case, then you need to make sure that your entities are serializable. The session itself is. Theoretically, you can serialize it back & forth between servers. In practice, I would feel much better if you used sticky sessions, though. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment14http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment14Thu, 13 Aug 2009 18:40:18 GMTRik, Caching? http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment13http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment13Thu, 13 Aug 2009 18:36:44 GMTRight now, I am searching for the holy pattern to span a session through multiple requests. One approach could be to record every request, that modifies the entity, and before each request, just replay (re-apply) them on the entity. This would work for very simple scenarios, but often, the commands take effect on a whole aggregate, not just a standalone entity. So now, the session-per-conversation pattern seems to be the most viable solution for me, with all of it's limitations. Until you suggest me a better one... http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment12http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment12Thu, 13 Aug 2009 17:16:55 GMTQuestion: how does the session per request deal with this very common scenario: a user retrieve the data for viewing in the first request and edits and submit his changes in a second request. You can argue to re-attach the entity on the second request but you will lose all the tracking information. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment11http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment11Thu, 13 Aug 2009 17:09:09 GMT@Tyler Exactly what I mean with "WEB app should have it in mind". http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment10http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment10Thu, 13 Aug 2009 16:34:19 GMTFor requests that span multiple pages I generally don't write the data to the actual entity until the very last screen is submitted. I keep track of the previous pages' data via hidden form fields. OR, I create a separate persistent model solely to save the user's progress. When the last screen is complete I then copy that "form" entity's data into the "business" entity. This does seem like more work at the outset, but it's a hell of a lot easier than managing a long conversation by dropping the NH session into the ASP session and all of the problems with concurrency that creates. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment9http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment9Thu, 13 Aug 2009 16:28:57 GMTSimple long-conversation management [code.google.com/.../NHExtendedSessionWebModule.cs](http://code.google.com/p/unhaddins/source/browse/trunk/uNhAddIns/uNhAddIns.Web/NHExtendedSessionWebModule.cs) Restriction: only one long conv. allowed This is the other pattern [fabiomaulo.blogspot.com/.../...nversation-per.html](http://fabiomaulo.blogspot.com/2009/01/aspect-conversation-per.html) Note: the usage of long conversation are not recommended in applications where the hardware scalability is mandatory. session-per-request is the better pattern in WEB and and the design of the WEB app should have it in mind. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment8http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment8Thu, 13 Aug 2009 16:02:25 GMT>but is that really a good idea? From my point of view, I hate aspnet session, now I avoid these like plague, it's not yet to the point of viewstate and dataset but I feel it'll be soon reaching that point... Unfortunnatly, at work I've seen SqlTransaction objects being serialized inside asp.net session inside web services... :( Happily that I don't have to look much into the code of these WS... http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment7http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment7Thu, 13 Aug 2009 14:38:57 GMTOn a side note: the "future posts" section gives me something to look forward to. For instance, the "8 days: Help requests that make me want to cry" sounds like a good one. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment6http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment6Thu, 13 Aug 2009 14:20:44 GMTAlso, using the ASP.NET session doesn't scale. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment5http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment5Thu, 13 Aug 2009 14:19:00 GMTYou suggest putting the NHibernate session in the ASP.NET session, but is that really a good idea? What if you are load balancing the web servers? What if you are using SQL Session Persistence? http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment4http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment4Thu, 13 Aug 2009 14:11:05 GMTI'm curious how you have the UOW span multiple requests when you are in a multi-server webfarm. Does nHib session work ok when de-/re-serialized through the out-of-proc session state providers? http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment3http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment3Thu, 13 Aug 2009 13:48:13 GMT"It is much easier to build your application so each request is a single unit of work." When a user is 'building' a possibly-temporary entity from the (web) UI, they may cause dozens of requests when moving between pages and with AJAX. I'm interested to know how you (Oren) handle this common situation without a unit of work which spans HTTP requests. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment2http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment2Thu, 13 Aug 2009 12:01:01 GMTHi, having such feature is very convenient. In the company I'm working for we are using 'Sooda' ORM and it's capable of serializing and deserializing transaction state. Using this we can implement long living 'transactions' that span multiple http requests. Transaction state is serialized to xml files, so even in case of application restart users will not lose their uncommited data and can continue working as if nothing happened. BTW by transaction state I mean the state of all objects inserted or modified in single ORM session. I havent yet tried to do the same with NHibernate, but hope it's possible. http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment1http://ayende.com/4117/nhibernate-unit-of-work-multiple-reuqests#comment1Thu, 13 Aug 2009 10:56:48 GMT