Re: jdbc xa patches
От | Oliver Jowett |
---|---|
Тема | Re: jdbc xa patches |
Дата | |
Msg-id | 42E71B5D.5000609@opencloud.com обсуждение исходный текст |
Ответ на | Re: jdbc xa patches (Michael Allman <msa@allman.ms>) |
Список | pgsql-jdbc |
Michael Allman wrote: > First, I'm assuming that any general release of the JDBC driver with XA > support will make it clear up front that it requires Postgres 8.1. Sure, but not everyone reads documentation before posting "problems" to the list. > With that in mind, if some mortal is foolish enough to attempt to > prepare a transaction on an unsupported backend, executeUpdate() will > barf up an SQLException, which will cause PGXAResource to throw an > XAException yada yada yada which will cause the TM to rollback the > transaction. So at least they won't be in Dangling Transaction Hell. Well, that's a given; I'd be complaining much more loudly if it silently ate errors! > Anyway, I'm counting on Postgres users knowing what they're doing, esp. > with something as non-trivial as XA support. You can't really assume that users of XA are familiar with the details of our particular XA implemenation, like "a syntax error at this point means your backend is too old". Back to my original point: It Needs A Better Error Message. How you do this I don't really care, checking the server version just seemed like the most reliable way to distinguish "it doesn't support 2PC" from "some random connection error". >> Isn't that covered by tracking the state of the one transaction that's >> currently in progress on the connection? i.e. if you get asked to >> rollback() while it's active, you do a rollback(); otherwise you do a >> ROLLBACK PREPARED. > > I think you're right. I also think this is a matter of style/personal > preference. I like to give classes some of the responsibility for their > correct usage. It makes it easier to diagnose problems when a class > instance is used incorrectly. My point was you can still do 90% of this without the extra complexity, and the other 10% will get handled by the server (if, for example, a broken TM asks to commit a transaction that was never prepared) Complexity is bad for maintenance. I'm probably going to end up at least helping with maintenance of this code, which is why I'm complaining up front. -O
В списке pgsql-jdbc по дате отправления: