Re: PostgreSQL XAResource & GlassFish 3.1.2.2
От | Heikki Linnakangas |
---|---|
Тема | Re: PostgreSQL XAResource & GlassFish 3.1.2.2 |
Дата | |
Msg-id | 511B8E0D.6010103@vmware.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL XAResource & GlassFish 3.1.2.2 (Bryan Varner <bvarner@polarislabs.com>) |
Ответы |
Re: PostgreSQL XAResource & GlassFish 3.1.2.2
Re: PostgreSQL XAResource & GlassFish 3.1.2.2 |
Список | pgsql-jdbc |
On 13.02.2013 04:28, Bryan Varner wrote: > So, in our testing, this has eliminated one source of error. We do see -some- improvement. > > However, I'm -very- confused about why the XAResource implementation for postgres has so many condition checks, why it'stracking what xid was being serviced by the resource (these are global). It seems like the XAResource implementationisn't trusting the global transaction manager to actually track xids to resources. That's one reason. Bugs in transaction managers are not unheard of. Getting useful error messages instead of than strange undefined behavior if you call the methods in a wrong sequence is useful in those scenarios. It's also highly useful for debugging purposes, if you're developing a transaction manager. Another reason is that because the implementation doesn't support transaction interleaving and suspend/resume, it checks that the transaction manager doesn't try to do that. If it does, you get a meaningful error, "Transaction interleaving not implemented". That's a clue to the user to configure the transaction manager to not do that. > Is this due to the overly simplistic isSameRM method, where it's not actually comparing if the resources is the same resourcerather than the same rmid (pointer to an XAResource)? I didn't fully understand that sentence, but no, it's not related to the fact that we have one XAResource instance per connection. > I'm not an XA expert, but I've been doing some comparison / contrasting to other open source implementations, and it seemslike other implementations are merely tracking some simple state (are we in a global tx or not?) but none of them areenforcing the restrictions the PG resource is regarding currentxid. I guess it depends on the underlying DBMS. Many drivers just pass on the start/end calls to the backend, and the backend handles tracking the state. Also, some drivers are simply not as strict on sanity-checking the incoming calls, and will fail silently if the transaction manager does something goofy. - Heikki
В списке pgsql-jdbc по дате отправления: