jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dolan, Kelly" <kdo...@inmedius.com>
Subject Understanding Sessions within Transactions
Date Mon, 08 Jul 2013 16:28:54 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message