On 8/9/07, Cris Daniluk <[EMAIL PROTECTED]> wrote: > After reviewing some of the code, I think the problem is quite simply > that Jackrabbit does something inherently incorrect - it attempts to > provide guaranteed transactionality for all persistence managers. I > think the transactionality must be applied and enforced at the PM, > with help from the core API as well. Not all PMs are transactional, > nor are they required to be by the JCR. In other words, a provider > could give the optional transactional support for some of its PMs but > not all. > > I think the intent of that decision was for this very reason. > > 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
