I logged a similar issue: https://issues.apache.org/jira/browse/JCR-1050.
It seems to me that Jackrabbit needs to decide if it is a data store or
if it leverages one. If it leverages one it should delegate the
transactional handling to the data store. If it is one is, there is a
lot of work to be done to ensure that transaction isolation levels are
respected, synchronization should not be the default state of the
repository. Regardless of this question, it seems that there is a lot
of work to be done to rework some of the persistence mechanisms to
delegate transaction management to the container. I understand that
there is some thought to run jackrabbit in an embedded mechanism,
however, so far it seems fairly closely tied to running within (at
least) a servlet container. I like the suggestion of creating different
PMs for different cases. Further use of OSGi (as suggested by Sling)
could create a nice plugin mechanism for leveraging different PMs
(although the current xml based configuration files also address this).
-paddy
Cris Daniluk wrote:
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
