jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Date Fri, 10 Aug 2007 07:32:10 GMT
On 8/9/07, Cris Daniluk <cris.daniluk@gmail.com> 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


View raw message