jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dolan, Kelly" <kdo...@inmedius.com>
Subject RE: Session object reuse?
Date Thu, 06 Feb 2014 17:55:45 GMT
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: justinedelson@gmail.com [mailto:justinedelson@gmail.com] On Behalf Of Justin Edelson
Sent: Wednesday, February 05, 2014 12:03 PM
To: dev@jackrabbit.apache.org
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 <kdolan@inmedius.com> 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: justinedelson@gmail.com [mailto:justinedelson@gmail.com] On 
> Behalf Of Justin Edelson
> Sent: Wednesday, February 05, 2014 11:13 AM
> To: dev@jackrabbit.apache.org
> 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 <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