Re: Postgres XA support

> 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