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 Thu, 06 Feb 2014 18:16:34 GMT
Hi Kelly,
If I understand your question, this is covered by section 21.3 of the
JCR 2 specification:

"Within a
transaction, changes made by save  (or other, workspace-direct, methods) are
transactionalized and are only persisted and published (made visible to other
sessions), upon commit of the transaction. A rollback will,
conversely, revert the
effects of any saves or workspace-direct methods called within the transaction.

Note, however, that changes made in the transient storage are not  recorded by a
transaction. This means that a rollback will not revert changes made to the
transient storage of the Session . After a rollback the Session
object state will
still contain any pending changes that were present before the rollback."

To be clear, when I wrote "transaction" earlier in this thread, I was
not refering to a formal JTA transaction. I meant it in a more casual
sense. I personally don't find mysefl using JTA transactions in (pure)
JCR applications very much. Instead, I use session creation and save()
as the transaction boundaries.

Regards,
Justin

On Thu, Feb 6, 2014 at 12:55 PM, Dolan, Kelly <kdolan@inmedius.com> wrote:
> 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