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

Re: jdbc xa patches

From: Michael Allman <msa(at)allman(dot)ms>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: jdbc xa patches
Date: 2005-07-27 03:28:13
Message-ID: 20050726225605.T74424@yvyyl (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
On Wed, 27 Jul 2005, Oliver Jowett wrote:

> I don't see any major problems with integrating this. Random comments:
> We now use 4-space indents, not tabs.

I'm away from my normal dev machine and am flailing away with unfamiliar 
tools.  Do you have a utility that will indent as desired?

> Do you have changes to build.xml to handle conditional compilation of
> the XA code only when the XA classes are available?

Yes.  I would send a diff but I don't have diff right now (see above).  I 
am attaching the entire build.xml.

> Is the test code ready to hook into the standard testsuite? Or are you
> anticipating a separate test run in the 'tests' target that invokes
> XATestSuite?

Hmmm . . . I'm not sure how you run tests.  I created an XATestSuite class 
in anticipation of using it to run all the XA-related JUnit test case 

> Is there any reason why the XA datasource needs to be a separate class?
> i.e. can we roll that functionality into all our datasources and put it
> at the top of the hierarchy somewhere? My only concern there is
> availability of the XA classes over different JDBC versions, we may need
> more conditional compilation, or use token substitution to comment out
> the XA code when the classes aren't available.

In creating PGXADataSource I followed the example of 

Also, an XADataSource is special in certain ways other than simple having 
a method to vend XAConnection instances, e.g. all XADataSource vended 
connections are set to "manual commit" (whatever you call the opposite of 
auto commit).

> Shouldn't the XAResource check the server version on construction or on
> start()/recover() to make sure that it's actually going to be able to
> use PREPARE TRANSACTION later? Or is erroring out with a syntax error at
> the point of prepare() sufficient? (I'd like to see a better error
> message there at least)

If we call statement.executeUpdate("SOME QUERY POSTGRESQL DOESN'T 
UNDERSTAND") will it throw an instance of SQLException?

> I'm not entirely happy about defaulting to autocommit=off on connections
> retrieved from the datasource. I understand that it needs to be off
> before you can actually do an XA start(), but I don't like defaulting to
> off as the Connection docs do say that connections start out with
> autocommit on. Also, can we check in start() rather than on getXAResource()?

The underlying physical connection starts in auto-commit mode, as 
required.  Before the client gets a handle to it, it is set to 
non-auto-commit mode because the connection comes from an XADataSource.

I think the following from the JDBC 3.0 spec, section 10.1.1 supports my 

The default is for auto-commit mode to be enabled when the 
Connection object is created. If the value of auto-commit is changed in 
the middle of a transaction, the current transaction is committed. It is 
an error to enable auto-commit for a connection participating in a 
distributed transaction, as described in Chapter 12 "Distributed 

Other than defaulting to non-auto-commit, I haven't given much thought to 
checking its state in PGXAResource.  If someone sets a connection 
participating in TPC to auto-commit, they're going to have problems one 
way or another.

> Having ResourceAssociationState as a full-blown class seems like
> overkill since you only have one instance anyway.

Maybe.  Java 1.4 doesn't have enums.  What do you suggest as an 

> Is XID_TO_TRANSACTION_STATE_MAP actually necessary? It seems like it's
> only there for detecting XA protocol errors (which would otherwise show
> up as errors from the backend, e.g. trying to commit a nonexistant
> transaction), and for tracking the state of the transaction that is
> currently suspended or currently associated (of which there can only be
> one in the current implementation)

In the implementation of rollback() it is used to determine whether to 
call physicalConnection.rollback() or issue a "ROLLBACK PREPARED" query.

> I'm not sure it's necessary for recover() to avoid returning
> non-JDBC-originated transactions; from memory the TM is already required
> to handle recovered Xids that were not generated by it. (need to check
> the XA spec here)

Quite the opposite.  The TM is required to ignore xids that were not 
generated by it.

Think about it --- how would TM1 know how to recover a transaction branch 
created by TM2?  Only TM2 knows what resources where participating in that 

Besides, if someone prepares a transaction with id "whatever", we aren't 
going to be able to decode that to an xid.

Thanks for your attention.


Attachment: build.xml
Description: text/plain (18.6 KB)

In response to


pgsql-jdbc by date

Next:From: Michael AllmanDate: 2005-07-27 03:40:33
Subject: Re: jdbc xa patches
Previous:From: Oliver JowettDate: 2005-07-27 01:26:05
Subject: Re: jdbc xa patches

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