Heikki Linnakangas wrote:
> This is essentially impossible with approach B, if the ... part uses the
> connection for some other xid. Otherwise, should work.
Right, I was thinking about implications for the other approaches.
> Note that the XA term "thread of control" actually means a connection in
> JTA terms. It doesn't make any difference which java thread does work.
> See JTA spec, section 3.4.3.
Ah, ok, that makes a lot more sense then :-)
> I'm leaning towards approach C myself [...]
Blocking seems really dangerous :( It seems quite likely that you could
deadlock against yourself..
> since it's the simplest to
> implement and doesn't cause any unexpected prepares.
Yeah, I thought some more about that and B is really bad from the
unexpected prepare angle. If we're preparing before the TM asks us to
(and therefore have transaction showing up as prepared in recovery) it
seems possible that a TM will incorrectly decide to commit those after
> Or possibly even violating the spec and not allowing to start another transaction before the previous one has been prepared.
This actually sounds like the best thing now as it produces obvious,
easy-to-diagnose errors when you do something that the driver doesn't
In response to
pgsql-jdbc by date
|Next:||From: Dave Cramer||Date: 2005-06-30 23:45:18|
|Subject: Re: jdbc cts final diff for review|
|Previous:||From: Kris Jurka||Date: 2005-06-30 20:31:31|
|Subject: Re: Problem with datestyle and driver jdbc|