Re: Postgres XA support - Mailing list pgsql-jdbc

> Ludovic Orban wrote:
>>  From the comments I saw in the source, transaction interleaving, join
>> and suspend/resume are still not supported and forget is still
>> unimplemented. This means you cannot mix local and global
>> transactions, cannot support EJBs with REQUIRES_NEW CMT declaration
>> and can get into troubles during crash recovery.

Can you clarify how that can get you into trouble during crash recovery?

We had a discussion about this earlier, and it seems I never replied to
your latest comment on the EJB REQUIRES_NEW support. Let me do that now:

Ludovic Orban wrote:
 > Heikki Linnakangas wrote:
 >> Ludovic Orban wrote:
 >>> Appart from that, suspend/resume is mandatory to implement CMT
 >>> REQUIRES_NEW semantics of the EJB servers.
 >>
 >> Why? Can't you just open a new connection on a REQUIRES_NEW method
 >> call?
 >
 > REQUIRES_NEW requires to start a brand new transaction for the
 > duration of the call. The only way to do this is to sak the TM to
 > suspend the current transaction, start the new one and when it's
 > finished resume the first one.
 >
 > Since a transaction is bound to a thread the is no way to do this
 > other than suspend/resume.

AFAICS, the transaction manager can simply keep the original connection
associated with the original transaction, and open a new connection
associated with the new transaction when needed. Can you give a specific
example scenario that's impossible to implement without suspend/resume
support?

>> I think it was Michael Allman that said the engine wasn't able to
>> properly support XA in Aug 2005 and unfortunately it seems that things
>> haven't changed much since then.
>>
>> I'm afraid you still have some work to do on the engine before you can
>> implement XA in JDBC.
>
> Well there are two perspectives on this.  If you need a way of
> implementing multi-resource transactions, than the simple two phase
> commit approach implemented in postgresql is adequate.  If full XA
> compliance is required then postgresql comes up far short.  Yes, backend
> development has stalled on this.  Backend developers were not aware of
> the full XA requirements and when informed said, "We implemented all
> this two phase stuff and now you're telling us it's inadequate!"  So
> they've moved on and the ability to do things like transaction
> interleaving are very complicated given the postgresql backend model, so
> I wouldn't hold my breath on things changing anytime soon.

I don't see much value in implementing the full XA spec. What we have
now is enough to implement distributed transactions reliably, and that's
what XA is all about.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com