> > I would recommend creating a TransactionalPersistenceManager interface > > and implementing it where appropriate. If someone tries to register an > > XA transaction while a non-transactional PM is in use, it would throw > > an immediate UnsupportedOperationException. > > > > - Cris > > > > This is a good argument and has at one point been taken into > consideration while implementing JTA support in Jackrabbit. The > problem about this approach turned out to be the following: the PM API > does not have a notion of "identity" or "origin" of a change: it is > meant to be a very simple interface that unconditionally and > atomically stores nodes and properties into whatever format it likes. > The PM again is getting called by the SharedItemStateManager who > maintains the cache of all items that have neither been modified in > the transient space nor saved but not yet committed. If handling > transactions would be delegated to a transactional PM, not only this > component, but also the SharedItemStateManager would need considerable > rework. > > Dominique >
This is an interesting point, and I guess it underscores the complexity of transactions and the general reason that MySQL went for 10 years saying they sucked before they figured out how to properly implement them :) Clearly the level of effort described shows this getting away from a 1.x change (or 1.3.x, at least). It nonetheless seems most appropriate, though. What would be the most appropriate way to discuss something like this in "code form"? For example, if I were to submit a fairly hefty patch from a relatively recent stable-line build, would someone be able to incorporate it, if appropriate? I'm not sure it even makes sense to talk about in this fashion, since it is almost too large to handle in a single patch, but I'm not sure how to go about moving forward.. - Cris
