Initializing VersionHistories inside transactions

["Daglian, Michael (IT)" <Mi...@morganstanley.com>]

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.