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 > >
