Skip site navigation (1) Skip section navigation (2)

Re: Postgres XA support

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 (view raw or flat)
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

In response to

Responses

pgsql-jdbc by date

Next:From: Ludovic OrbanDate: 2006-10-09 11:08:56
Subject: Re: Postgres XA support
Previous:From: Heikki LinnakangasDate: 2006-10-09 10:53:41
Subject: Re: Postgres XA support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group