Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <e176788c0707250237w6bc82b18mf0b000f698cac1e3@mail.gmail.com>
Date: Wed, 25 Jul 2007 11:37:06 +0200
From: "Dominique Pfister" <dominique.pfister@day.com>
Sender: dpfister@day.com
To: dev@jackrabbit.apache.org
Subject: Re: Questions about TX in Jackrabbit, JTA and Spec compliance
In-Reply-To: <46A6058B.3080901@consol.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4691F684.4080703@consol.de>
	 <e176788c0707240225i46412dd2q67bd5d9534be07d1@mail.gmail.com>
	 <46A6058B.3080901@consol.de>

Hi Marcel,

On 7/24/07, Marcel May <marcel.may@consol.de> wrote:
> Jackrabbit JCA basically wraps Jackrabbit Core, but still all the Core
> PersistenceManager and FileSystem implementations
> are used. These, as you mentioned as well, use and manager their own
> JDBC connections and therefore can never be JTA/XA compliant:
>
> - JTA/XA requires using a (distributed) transaction manager
> - Jackrabbit directly invokes setAutoCommit/commit/rollback without a
> transaction manager (illegal in JTA/XA terms!)
> - Jackrabbit  Workspace with a DB FileSystem and DB PersistenceManager
> have two separate configured connections w/o a transaction manager.
>
> Example:
> - If Jackrabbit rolls back a TX directly on a connection, the
> distributed transaction will not know about this.
> - If the distributed TX is rolled back, Jackrabbit might already have
> invoked con.commit() ... therefore no
>   rollback is possible.

When using Jackrabbit JCA, every repository operation made on behalf
of a distributed transaction is recorded in a "change log", something
not associated with the JDBC connection used normally. This change log
will not be persisted on invididual "save" calls, but only when the
respective method calls on the XAResource interface, exposed by
Jackrabbit JCA, are invoked. Therefore, I don't think the situations
you describe are actually encountered.

> Spec says a JCR impl can support TXs, and if it supports TXs it must
> support JTA. Right?

I'd say so.

> The Jackrabbit impl. can not be transactional on workspace level if
> internally a
> database PersistenceManager and a databasse FileSystem each have their
> own database connection:
> An operation spawns the persistence manager (=pm) and the filesystem
> (=fm), right?
> If one part (fm/pm) succeeds  and is commited, the other part (fm/pm)
> might fail and
> therefore violate the ACID principle?
> How do the two db connections of PM and FS work together?
> This IMO can only be managed by  JTA/XA.

AFAIK, the FS is mainly used for configuration purposes and therefore
plays an important role on startup. PM, on the other side, is the one
used when it comes to saving content in the repository. You're right,
that a combination of PM/FS operations is conceivable where one side
reports success and the other doesn't, but that shouldn't happen in
real life.

Again, when using Jackrabbit JCA, every operation that could
potentially end up in a JDBC call writing some data, is rather logged
to some internal storage and only executed when the distributed
transaction is committed. It is only at that point in time, that all
changes are written at one time using the PM's JDBC connection.

Cheers
Dominique

> P.S.: I'd be willing to provide a documentation patch at the end of this discussion :-)

Always happy to find some volunteers :-)