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