Understanding Sessions within Transactions

["Dolan, Kelly" <kd...@inmedius.com>]

I inherited some application code that embeds a Jackrabbit 1.6.1 repository and encounters exceptions like "StaleItemStateException: <item> has been modified externally" on commit of an XA transaction. The exceptions are random - e.g., sometimes an operation succeeds, sometimes it fails - and <item> differs from time to time.

Section 8.1.4 of the JCR specification shows the use of a single session across multiple transactions but from I can tell, the application I'm dealing with uses multiple sessions across a single transaction. For example (note this is very simplistic compared to the actual code),


a)      Class A starts transaction

b)      Class A calls MyAppJCRDelegate.doX(), does other stuff and then calls doY()

c)       Each method doX() and doY(), logs into a Session, invokes JCR APIs (e.g., add node, set property, save) and logs back out.

d)      Class A commits transaction

Questions:

1)      Should this work and be okay???

2)      From what I understand, the call to save() does not really persist the changes since it is a part of a transaction. Even so, does the Session object in doY() see the changes "saved" in doX()?

Information I can find re: the exception seems to indicate multiple threads are updating the same node. I found a background thread that pre-loads/caches certain repository nodes in the attempt to improve performance. "Get" related methods go to this application cache (and loads it from the repository if not there) but "set" related methods appear to operate directly on the repository (e.g., doX(), doY()) and then clear the corresponding cached node(s).

Questions:

3)      What impact, if any, on the example above would there be if somewhere between the start and end of the transaction, a background thread called MyAppJCRDelegate.doZ() which logged into a Session, invoked a "get" JCR APIs (e.g., get node, get property) and then logged back out? I assume the background thread is not a part of the transaction.

4)      Does the node/property returned by the background thread reflect the state of the node/property within the main thread/transaction? I'm guessing no.

Thanks,
Kelly

--
Kelly E. Dolan, Software Architect
Inmedius, a Boeing Company | www.inmedius.com<http://www.inmedius.com>
P: 412-459-0310 x211 | F: 412-459-0311