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

Reply via email to