jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister" <dominique.pfis...@day.com>
Subject Re: Questions about TX in Jackrabbit, JTA and Spec compliance
Date Thu, 02 Aug 2007 15:20:33 GMT
Hi Cris,

On 8/2/07, Cris Daniluk <cris.daniluk@gmail.com> wrote:
> I've been observing this thread, pondering, and feel the need to weigh in.
>

Cris, thanks a lot for your comments: they helped me understand what
Marcel's concerns are about the way Jackrabbit implements XA.

> Marcel's point here is that the JTA implementation doesn't allow the
> RDBMS transaction to participate in the XA. I can see a good argument
> for this - after all, Jackrabbit maintains an effective journal and
> not all RDBMS can participate in XA.
>
> That said, at the truest definition of a transaction, does just
> writing to the changelog truly constitute a guaranteed transaction?
> What if the RDBMS cannot be written to due to an integrity violation?
> I don't think the cohesion between the RDBMS and the Jackrabbit
> implementation are so tight that it is fair to argue any inconsistency
> would be similar to datafile corruption.

Where would that integrity violation come from? If you think of some
clustered environment, and some other node in a clustered environment
has made some modifications that changed the same items this node is
trying to update, it will get informed about the staleness of its copy
and throw. IMHO, looking at the very basic data model Jackrabbit uses
and if we rule out other programs that tamper around with the data, I
don't think this should happen.

> Also, as Marcel noted, a bundled persistence manager is going to
> potentially write to more than one RDBMS or file system - blobs, for
> example, are hashed out to the file system in the default bundle
> manager. I believe these blobs bypass the changelog (like blob writing
> in most systems).

I'd say that blobs use some temporary storage until they are saved, in
other words data is not written to shared storage before the
transaction is actually committed. Please correct me, if I'm wrong.

>                              Therefore, while you cannot ever guarantee true
> transactionality on the fs, I think Jackrabbit could come a bit closer
> by allowing the RDBMS node write and fs blob write to participate in
> the XA.

I'm not sure if I you get there: do you suggest that Jackrabbit, when
used with XA, uses some DB connection that is itself part of the same
XA transaction and managed by the transaction manager? I could then
imagine that some change made inside Jackrabbit to the database will
later be revoked because another part of the XA transaction has
failed, without Jackrabbit noticing it, which would leave to
inconsistencies.

Kind regards
Dominique

>
> Thoughts?
> > ---------- Forwarded message ----------
> > From: "Dominique Pfister" <dominique.pfister@day.com>
> > To: dev@jackrabbit.apache.org
> > Date: Wed, 25 Jul 2007 11:37:06 +0200
> > Subject: Re: Questions about TX in Jackrabbit, JTA and Spec compliance
> > 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 :-)
> >
> >
>

Mime
View raw message