On 13 February 2013 12:58, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> 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's tracking what xid was being
>> serviced by the resource (these are global). It seems like the XAResource
>> implementation isn'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.
Rightly so.
Even if we supported interleaving we'd still want those checks so we
can tell the difference between various types of request. It isn't
cool to assume that any TMJOIN request works with whatever the last
xid used was.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services