On Jun 30, 2005, at 2:37 PM, Heikki Linnakangas wrote:
> I'm leaning towards approach C myself, since it's the simplest to
> implement and doesn't cause any unexpected prepares. Or possibly
> even violating the spec and not allowing to start another
> transaction before the previous one has been prepared. It depends
> on how the popular application servers behave in real life.
'C' seems best to me also.
I'm using pg with a custom wrapper that fakes XA, and each
transaction gets its own physical connection from the pool. Depending
on how an appserver integrates connection pooling and their TM, it
might never be a problem.
Blocking shouldn't ever cause a deadlock, as the JTA timeout on the
transaction should kick in and forcibly rollback (this would happen
when used with JOTM, I can't vouch for other TM's). Could be some
nasty unexpected pauses though :)
A non-spec compliant switch would be nice too, as you suggest.
-pete
--
peter royal -> proyal@pace2020.com
