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 <[email protected]> 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: [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 >>> >>>
