Hi all, Not too bring up an issue that's been discussed on the lists before but I had a question about the ability to performed versioned operations inside of a transaction. Apologies if the existing JIRA items cover this but the Apache JIRA site seems to be down right now. It mainly concerns resource ordering inside the transaction w.r.t. the XAVersionManager (in release 1.1). Let me briefly describe our scenario: we have a simple JTA-like transaction module that treats each session on a different workspace accessed by a user as a single XA resource (i.e. as they modify nodes in multiple workspaces, each XASession is enlisted into a transaction that is managed as a single unit). Since the sessions each have their own XAVersionManager then, upon prepare, a StateItemStateException on the jcr:versionStorage root is thrown when versionable nodes from different workspaces have their version histories initialized. More specifically, this occurs during prepare of the second session as the modCount of the ItemState has increased to 1 (as expected) during the prepare of the first.
We tried a workaround with a custom XAVersionManager that only performed transactional operations once (i.e. all sessions in the transaction shared a single XAVersionManager instance). This worked around the stale state problem but introduced a new issue on some removes (and here my knowledge of the versioning system proved a limitation). Basically, my question is it possible to achieve what the above describes (version operations on different workspaces for the same user in a single transaction)? JCA isn't an option for us (though I am not sure if it would help with this problem). Thanks! Best Regards, -- Mike -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.