Re: XAResource implementation - Mailing list pgsql-jdbc

From joël Winteregg
Subject Re: XAResource implementation
Date
Msg-id 1194939010.5505.24.camel@hatman
Whole thread Raw
In response to Re: XAResource implementation  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: XAResource implementation
List pgsql-jdbc
Hello Heikki,

Many thanks for your answer and for the time you took to do some
testing ! As you can see I put Ludovic Orban as Cc because he is the BTM
developer and he seems to be interested to this issue too...

> Hmm. I downloaded the BTM newUserDemo.zip and modified it to run with
> Postgres, and to run two queries in same transaction. Works for me.
>

Ah Yes, you're right, your transaction just looks perfect !

> Attached is the modified Test.java I used. To run:
> 0. Download newUserDemo.zip from
> http://docs.codehaus.org/display/BTM/NewUserGuide
> 1. Put postgresql.jar in newUserDemo/lib
> 2. Copy the attached Test.java to newUserDemo/src/jtatest
> 3. Modify database/username/password in Test.java if necessary
> 4. Run the CREATE TABLE from derby-create.sql
>
> Here's what I get in the Postgres log, with log_statements='all':
>
> LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts
> LOG:  execute S_1: BEGIN
> LOG:  execute <unnamed>: insert into messages(content) values ($1)
> DETAIL:  parameters: $1 = 'hello, world!'
> LOG:  execute S_2: COMMIT
> LOG:  execute S_1: BEGIN
> LOG:  execute <unnamed>: select content from messages
> LOG:  execute <unnamed>: select content from messages
> LOG:  execute S_2: COMMIT

On my side, I tryed the following example:
http://docs.codehaus.org/download/attachments/9240687/HibernateBTM.zip?version=2

(see attachement to see my modifications)

and my pg logs look like this for the following code:
userTransaction.begin();
loopCountQuery(sf); //many select count queries
userTransaction.commit();


2007-11-13 08:13:51 CET DETAIL:  parameters: $1 = 'username 6'
2007-11-13 08:13:51 CET LOG:  execute S_2: COMMIT
2007-11-13 08:13:51 CET LOG:  execute S_1: BEGIN
2007-11-13 08:13:51 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:13:51 CET DETAIL:  parameters: $1 = 'username 7'
2007-11-13 08:13:51 CET LOG:  execute S_2: COMMIT
2007-11-13 08:13:51 CET LOG:  execute S_1: BEGIN
2007-11-13 08:13:51 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:13:51 CET DETAIL:  parameters: $1 = 'username 8'
2007-11-13 08:13:51 CET LOG:  execute S_2: COMMIT
2007-11-13 08:13:51 CET LOG:  execute S_1: BEGIN
2007-11-13 08:13:51 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:13:51 CET DETAIL:  parameters: $1 = 'username 9'
2007-11-13 08:13:51 CET LOG:  execute S_2: COMMIT
2007-11-13 08:13:51 CET LOG:  execute S_1: BEGIN
2007-11-13 08:13:51 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:13:51 CET DETAIL:  parameters: $1 = 'username 10'
2007-11-13 08:13:51 CET LOG:  execute S_2: COMMIT

When I use the pure JDBC driver (not the XA implementation), I don't
have this behaviour (BEGIN and COMMIT are related to userTransaction
from application level) and not anymore around each query:

2007-11-13 08:19:55 CET LOG:  execute S_1: BEGIN
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 0'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 1'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 2'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 3'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 4'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 5'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 6'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 7'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 8'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 9'
2007-11-13 08:19:55 CET LOG:  execute <unnamed>: select count(*) as y0_
from USERS this_ where this_.NAME=$1
2007-11-13 08:19:55 CET DETAIL:  parameters: $1 = 'username 10'
2007-11-13 08:19:55 CET LOG:  execute S_2: COMMIT


As I'm not a JTA and JDBC expert at all, I'm not able to provide you
more information, I'm sorry about that... I hope this behaviour is not
coming from my miss-understanding !


Thanks for your help !

Regards,

Joël

On Mon, 2007-11-12 at 09:59 +0000, Heikki Linnakangas wrote:
> joël Winteregg wrote:
> > I said that BTM TransactionManager was "mostly" working because when I
> > was using the XA implementation, SQL BEGIN and COMMIT where generated
> > arround each SQL query (even if several queries were located inside the
> > same transaction). So at the end, I used the TransactionManager with the
> > "Last Resource Commit Optimization" which allow the use of a pure jdbc
> > driver during transaction (I only have a single DB (1 Phase Commit) so
> > it is 100% safe to use this specificity). In this case, my BEGIN and
> > COMMIT statement where just perfect:
> > BEGIN
> >   SELECT ..
> >   SELECT ..
> >   SELECT ..
> > COMMIT
> >
> > So I was just wondering if my XA problem (BEGIN and COMMIT location when
> > using XA) could come from the postgresql XA driver ?
>
> Hmm. I downloaded the BTM newUserDemo.zip and modified it to run with
> Postgres, and to run two queries in same transaction. Works for me.
>
> Attached is the modified Test.java I used. To run:
> 0. Download newUserDemo.zip from
> http://docs.codehaus.org/display/BTM/NewUserGuide
> 1. Put postgresql.jar in newUserDemo/lib
> 2. Copy the attached Test.java to newUserDemo/src/jtatest
> 3. Modify database/username/password in Test.java if necessary
> 4. Run the CREATE TABLE from derby-create.sql
>
> Here's what I get in the Postgres log, with log_statements='all':
>
> LOG:  execute <unnamed>: SELECT gid FROM pg_prepared_xacts
> LOG:  execute S_1: BEGIN
> LOG:  execute <unnamed>: insert into messages(content) values ($1)
> DETAIL:  parameters: $1 = 'hello, world!'
> LOG:  execute S_2: COMMIT
> LOG:  execute S_1: BEGIN
> LOG:  execute <unnamed>: select content from messages
> LOG:  execute <unnamed>: select content from messages
> LOG:  execute S_2: COMMIT
>

Attachment

pgsql-jdbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: XAResource implementation
Next
From: Heikki Linnakangas
Date:
Subject: Re: XAResource implementation