jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: Session object reuse?
Date Wed, 05 Feb 2014 16:12:53 GMT
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 <kdolan@inmedius.com> 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
>
>

Mime
View raw message