Thanks! that sort-of helped me understand the purpose of Session, But then perhaps I asked the wrong question.
What can I do for caching? I'm using RIA Services with SL client. Suppose: a user pulls a list of tickets, then decides to update an existing ticket to make a change, say add a new Note (which is a new child entity) (we lock the ticket when the user edits, so concurrency of an item isn't an issue, with only a couple known and accounted for exceptions). If I have no persistent session/cache, i have to reload the entire Ticket graph from the database, just to insert a row into one table. (that's because the Ticket and its other children didn't change, so obviously they don't need to be sent back over the wire to the service) this seems like a lot of trips to the database. ------ Joe Brockhaus [email protected] ------------ On Tue, Mar 15, 2011 at 6:53 PM, John Davidson <[email protected]> wrote: > Even with web services the session-per-request pattern should be used and > ISession should never be stored in a singleton. It is possible to store the > SessionFactory in a singleton. > > A simple solution > > > http://nhforge.org/blogs/nhibernate/archive/2010/07/11/nhibernate-bootstrapper-unitofwork-and-sessionperrequest.aspx > > A more complex solution > > > http://nhforge.org/blogs/nhibernate/archive/2011/03/03/effective-nhibernate-session-management-for-web-apps.aspx > > > John Davidson > > On Tue, Mar 15, 2011 at 6:11 PM, Joe Brockhaus <[email protected]>wrote: > >> Hi all, >> >> I'm trying to get an indication of the best way to isolate work between my >> web service's various request threads, so they don't step on eachother's >> toes. >> >> My ISession is persistent across all web service calls. >> Currently, I'm creating a Transaction before doing any of the web >> service's work, then submitting that transaction when it's complete, but I'm >> not confident it's isolating the work the way i'd expect. >> >> -- Is this the correct way to go about this, or should i aggressively lock >> entities? >> ---- My only worry with locking entities in one web session, is that i'll >> be impossible to unlock them in the subsequent session (or that a new web >> service call will unlock an entity it's not supposed to) >> -- Should I create a child Session? >> ---- my only worry here is that I don't want to have to re-query the >> database any more than I have to. the singleton Session instance is >> providing me with this benefit. >> >> II can't seem to find a best-practices guide to isolating units of work - >> so if documentation exists somewhere and I'm just not seeing it, I'll take >> it as a starting point. >> >> TIA >> >> ------ >> Joe Brockhaus >> [email protected] >> ------ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
