geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ludovic orban" <ludovic.or...@gmail.com>
Subject XA_RDONLY optimization - question
Date Wed, 10 May 2006 20:17:47 GMT
Hi,

I carefully read Mike Spille's XA Exposed articles but there was
something I could never properly understand. I hope somebody here will
be able and kind enough to help me understand what I missed.


The question I have lies in "The 1PC Optimization..." paragraph of XA
Exposed - Part II
(http://jroller.com/page/pyrasun?entry=xa_exposed_part_ii_schwartz).

Quoting Mike :


...only 1 XAResource has actually done any useful work. Here are some
reasons why this can happen:

   * Only one transaction ever got enlisted. There are a number of
combinations of configuration and/or application logic that can lead
to this condition.
   * Every resource but one returned XA_RDONLY from its prepare() call

The 1PC optimization itself is very simple: the Transaction Manager
skips writing a "Committing..." record, it skips the prepare() call,
and calls commit() on the lone XA Resource directly.


Now I believe that the second point Mike enumerated (Every resource but
one returned XA_RDONLY from its prepare() call) is not consistent with
the ending sentence (writing a "Committing..." record, ==> it skips
the prepare() call <==). How can you trigger 1PC with the XA_RDONLY
vote ? You will only know the result of that vote after the prepare
call and then it's too late to commit with the 1PC optimization ! The
best you can do is skip the COMMITTING log record force while still
calling commit with 1PC boolean flag set to false on the sole resource
that returned XA_OK.

You end up with 2 disk forces in that case instead of the single one
you would get with a plain 1PC optimization.


I'd really appreciate if anyone could comment on this.

Thank you in advance,
Ludovic

Mime
View raw message