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 Mon, 06 Aug 2007 09:58:01 GMT
Hi Cris,

On 8/2/07, Cris Daniluk <cris.daniluk@gmail.com> wrote:
> In Oracle, a committed transaction means that it is in the redo log,
> but not necessarily written to the tablespace. However if you combine
> the tablespace+log, you are guaranteed to get a consistent
> point-in-time view of that transaction. Oracle could, and often does,
> have trouble writing from the log out to the tablespace (corruption,
> insufficient space, whatever), but there is no loss of data. You can
> further back up to that transaction and regardless of the location
> (tablespace or log) you are covered. I realize that this is a pretty
> crappy, simplified description of journaling, but it might help frame
> our discussion.
> My concern with Jackrabbit is whether the changelog is a true journal
> or a mere queue for the database. For example, once a transaction is
> committed and written to the changelog, but before it is written to
> the RDBMS, is it part of the "logical view"? In other words, if I
> query JR before the flush to the DB, will I see my newly committed
> data? If I crash before the RDBMS write happens and start up, am I
> safe?

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

> 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?

Kind regards

> Thanks for your responses thusfar!
> - Cris

View raw message