Cache information for NHibernate is at: http://nhforge.org/doc/nh/en/index.html#performance-cache
Implementing this correctly could save the additional round trips, also Microsoft has a sample at http://archive.msdn.microsoft.com/RiaServices John Davidson On Wed, Mar 16, 2011 at 5:27 PM, Joe Brockhaus <[email protected]> wrote: > 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. > -- 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.
