Hi Cris, On 8/2/07, Cris Daniluk <[EMAIL PROTECTED]> 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 memory-based. > 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 Dominique > > Thanks for your responses thusfar! > > - Cris >
