Re: XA support

From: Dave Cramer <davec(at)fastcrypt(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: XA support
Date: 2005-06-30 19:08:01
Message-ID: D90E9D45-AA91-4145-8E35-5D8A9010B3BD@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Heikki,

The folks at JONAS want to test the driver so I'd think they would
work with you on this.
Post this on the pgj2ee list.

Dave
On 30-Jun-05, at 2:37 PM, Heikki Linnakangas wrote:

> On Thu, 30 Jun 2005, Oliver Jowett wrote:
>
>
>> Heikki Linnakangas wrote:
>>
>>
>>> B. When the second transaction starts, the first transaction is
>>> prepared
>>> behind the scenes, freeing the connection for the new transaction.
>>>
>>
>> This is probably the way to go initially, since it's much simpler. It
>> should also deal with the more common uses of XA where you're just
>> coordinating 2 or more resources in an otherwise straightforward
>> begin-do stuff-commit sequence. We can get clever later :)
>>
>> Related issues: supporting this case:
>>
>> xaRes.start(xid1, XAResource.TMNOFLAGS);
>> stmt.executeUpdate("...");
>> xaRes.end(xid1, XAResource.TMSUSPEND);
>> // ...
>> xaRes.start(xid1, XAResource.TMRESUME);
>> stmt.executeUpdate("...");
>> xaRes.end(xid1, XAResource.TMSUCCESS);
>>
>
> This is essentially impossible with approach B, if the ... part
> uses the connection for some other xid. Otherwise, should work.
>
>
>> and this one:
>>
>> xaRes.start(xid1, XAResource.TMNOFLAGS);
>> stmt.executeUpdate("...");
>> xaRes.end(xid1, XAResource.TMSUCCESS);
>> // ...
>> xaRes.start(xid1, XAResource.TMJOIN);
>> stmt.executeUpdate("...");
>> xaRes.end(xid1, XAResource.TMSUCCESS);
>>
>
> Practically the same as above, really.
>
>
>> and this one (yow!):
>>
>> (thread 1):
>> xaRes.start(xid1, XAResource.TMNOFLAGS);
>> stmt.executeUpdate("...");
>>
>> (thread 2):
>> xaRes.start(xid1, XAResource.TMJOIN);
>> stmt.executeUpdate("...");
>>
>
> Note that the XA term "thread of control" actually means a
> connection in JTA terms. It doesn't make any difference which java
> thread does work. See JTA spec, section 3.4.3.
>
> I'm leaning towards approach C myself, since it's the simplest to
> implement and doesn't cause any unexpected prepares. Or possibly
> even violating the spec and not allowing to start another
> transaction before the previous one has been prepared. It depends
> on how the popular application servers behave in real life.
>
> - Heikki
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Alberto Molteni 2005-06-30 20:17:37 Problem with datestyle and driver jdbc
Previous Message Heikki Linnakangas 2005-06-30 18:37:16 Re: XA support