On May 10, 2006, at 10:47 PM, ludovic orban wrote:
David,
1. there's only one resource in the transaction. Well, you can just
call 1pc commit on it. As a special case, if there are lots of
resources, but all but the last one says it's read-only, you can just
call 1pc commit on the last one (skipping prepare). I think it's
sort of obvious this works, and doesn't introduce any risks of data
loss.
I agree on this but running the prepare calls in parallel voids the
special case of the last resource returning read-only.
2. if your last resource only supports 1pc (it's not xa) some people
think you can just call commit on it, and then write the prepare
record for the other participants: you use the result of this 1pc
commit to decide whether to proceed or roll back the other
participants. A little thought shows that the time between the
completion of the 1pc commit and writing the prepare record to the
log is vulnerable and can result in inconsistency. (many people
don't seem to realize this).
This is what Mike calls 'Last Resource Gambit'. It's main usage is to
allow non-XA resources to participate in 2PC, it has very little to do
with transaction speed optimization. I personally refuse to use that
trick since it's not ACID.
However, there's a trick that can make
it work :-) If you store the transaction log in the 1pc resource,
and only do the commit as a part of writing the prepare record to the
log (ignoring the 1pc commit call directly to the resource) then the
semantics work out properly. AFAIK Jeremy Boynes thought this up,
and I've implemented it in geronimo, but so far there is no testing
of it.
BEA implemented this in Weblogic 9 and called it 'Logging Last
Resource' (http://edocs.bea.com/wls/docs90/jta/llr.html).
The good points of this technique are that you can use a non-XA
resource in 2PC while staying 100% ACID and you get a slight
performance boost if you only use 2 resources in the transaction.
The bad points are that if you use more than 2 resources this method
is slower than using a file based tx log and also it messes up a bit
your DB schema since you have to create some tx log table(s) in the
same DB schema. It also can only work if the resource is a database.
So if I properly deciphered your email, the XA_RDONLY vote is pretty
much useless since it only allows a 1PC optimization on the last
resource to be prepared and only if your don't run prepare calls in
parallel.
Am I right ?
As far as I can tell, yes :-)
thanks
david jencks
Thank you,
Ludovic
