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
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
> 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.
Description: text/plain (18.6 KB)
In response to
pgsql-jdbc by date
|Next:||From: Michael Allman||Date: 2005-07-27 03:40:33|
|Subject: Re: jdbc xa patches|
|Previous:||From: Oliver Jowett||Date: 2005-07-27 01:26:05|
|Subject: Re: jdbc xa patches|