jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Padraic Hannon <...@wasabicowboy.com>
Subject Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Date Thu, 09 Aug 2007 17:31:58 GMT
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).


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

View raw message