jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cris Daniluk" <cris.dani...@gmail.com>
Subject Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Date Mon, 06 Aug 2007 13:01:57 GMT
> The changelog is filled with the operations BEFORE the transaction is
> committed, and its contents is part of the logical view, as far as
> node traversal is concerned. In other words, before the transaction is
> committed, you will be the only one seeing those changes, and after
> commit, everyone will. However, if JR crashes before the changelog has
> been saved to the RDBMS, the changelog will be lost, as it is
> memory-based.

This is where our concern comes in. Based on your explanation,
Jackrabbit is not honoring the JTA spec, nor the general ACID
transaction principals (durability, notably). The fact that the
committed transaction rolls into the logical view is great, but the
fact that there is no flush to permanent storage is not.

The JTA spec is bound to the X/Open DTP standard, available at

I think the spec clearly sets the expectation for transaction
permanence, and I believe that Jackrabbit clearly misses that, so
while I think that the JTA support offered is valuable, it is not
truly compliant--probably in a way that would be surprising to most
JTA users.

> > If the XA includes Jackrabbit AND the RDBMS AND any other outside
> > participants that may be relevant, it could not be rolled back without
> > Jackrabbit knowing. I'm not sure I understand where Jackrabbit could
> > be "left out of the loop" on a rollback?
> I just have some concerns about the flow of control: what JR is
> supposed to do with its associated JDBC connection when a XA TX is
> prepared, committed or rolled back. Do I get your point here: instead
> of using a changelog, continuously write changes made by the client
> via XA capable JDBC connection to the database, using the fact that
> uncommitted changes are only visible to that user?

If the DBMS supports the two-phase transaction (I believe Postgres
does), then you could just use a JTA-enabled version of the JDBC
driver and register the DB transaction to the existing XA. Then, while
you execute the SQL directly to the RDBMS, it would not be visible as
it is not committed. When the global transaction is committed, the
DBMS would receive the two-phase commit request(s) and do the right
thing automatically.

The only other option is to persist the changelog, effectively
converting it into a journal. However, I think bringing the DBMS into
the XA is probably the quickest way to solve this problem..

- Cris

View raw message