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 Thu, 09 Aug 2007 14:59:51 GMT
> > Hm, I doubt that. JR at its core stores content with calls to an
> > abstract interface, namely the Persistence Manager. It is this
> > component that may store nodes and properties inside a DBMS, via JDBC
> > calls over a single connection it acquired on startup. Changing this
> > to using a transaction-local JDBC connection looks more complex to me
> > than persisting the change log.
> >
>
> Based on that design, persisting the change log is probably the way to
> go. If you're using a single connection to write back to the DBMS,
> that log could easily become very lengthy. I think the performance
> overhead of writing to disk and flushing it would be utterly
> insignificant (synchronous db writing is far more expensive
> performance-wise, yet JR still exhibits solid performance).
>

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

Mime
View raw message