From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Ludovic Orban <lorban(at)bitronix(dot)be> |
Cc: | Kris Jurka <jurka(at)ejurka(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Postgres XA support |
Date: | 2006-10-09 11:04:00 |
Message-ID: | 452A2CA0.2080900@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ludovic Orban | 2006-10-09 11:08:56 | Re: Postgres XA support |
Previous Message | Heikki Linnakangas | 2006-10-09 10:53:41 | Re: Postgres XA support |