Justin, I have one more question if you don't mind. If we set a property, call Session.save() but the overall transaction rolls back because some error occurs later, will the Session object reflect the *new* property? Or is it really only holding that new property until save() is called?
Kelly -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Justin Edelson Sent: Wednesday, February 05, 2014 12:03 PM To: [email protected] Subject: Re: Session object reuse? Hi Kelly, Yes, I meant does NOT do a Session.save(). Session.refresh(false) could work, but I think that is going to be doing more work than you need. Another consideration should be security - reusing sessions is obviously only safe if the user identity is constant between session. Justin On Wed, Feb 5, 2014 at 10:45 AM, Dolan, Kelly <[email protected]> wrote: > Thanks Justin! We were thinking ThreadLocal. Did you mean to say "does NOT > do a Session.save()"? Also, would a Session.refresh(false) clear the *new* > property value in that case? So for example, on call of an API, get our > session object, call refresh(false), then perform the operation. > > Kelly > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Justin Edelson > Sent: Wednesday, February 05, 2014 11:13 AM > To: [email protected] > Subject: Re: Session object reuse? > > Hi Kelly, > It sounds like you should be scoping your Sessions at the transaction, not > the API level. Since you can't refactor the API, a ThreadLocal would probably > be the next best option. > > One significant issue which can arise from sharing Sessions between > transactions is that leftovers (for lack of a better term) from the first > transaction are seen in the second transaction. For example, if an API call > sets a property via its Session and then does do a Session.save(), the next > API call will see the *new* property value, which probably isn't what you > want. > > HTH, > Justin > > On Wed, Feb 5, 2014 at 8:40 AM, Dolan, Kelly <[email protected]> wrote: >> Help! Is there any reason Session objects should not or cannot be >> reused? If so, why? (Time is of the essence so I appreciate quick >> responses.) >> >> >> >> From the Jackrabbit documentation, we know Session objects are not >> thread-safe so we'd need to guard against this (we're thinking of >> associating a session w/ each thread in the thread pool). It also >> says its good practice to release resources, especially JCR sessions. >> But ours are constantly in use and constantly created/destroyed. Our >> biggest concern is if data would be corrupted/stale because logout() >> is not called on a session object that participated in a transaction. >> >> >> >> We are having performance problems, we need to quickly make some >> minor/low risk changes that can improve performance, and this is one >> change we are considering. We are currently using Jackrabbit 2.6.3. >> Our application architecture encapsulates Jackrabbit behind an >> interface that defines fine-grained APIs. Currently, on call of each >> API we login and create a new Session object (always w/ the same >> credentials), perform the function and then logout. The cost of the >> login/logout calls is significant when considering the APIs are >> called many times for one user operation (which is performed w/in a >> transaction). We plan to look at refactoring the APIs for the long term but >> this is just not possible at this time. >> >> >> >> Many, many thanks for guidance. >> >> >> >> Kelly >> >> >> >> -- >> >> Kelly E. Dolan, Software Architect >> >> Inmedius, a Boeing Company | www.inmedius.com >> >> P: 412-459-0310 x211 | F: 412-459-0311 >> >>
