Thread: XADataSource implementation

Hi,

I've been working on the XADataSource implementation. Patch attached. Test case
is in the separate zip file, because I couldn't get cvs to include it in the
diff.

I looked at Micheal Allman's implementation, but decided to continue working on
my original version instead. Michael's implementation was perhaps more
ambitious, it had more thorough bookkeeping for resource associations and xids.
Unfortunately there's no straightforward way to implement the full XA interface
in a spec-compliant way. I did copy some snippets and test cases from Michael's
code that were useful, though.

Thanks Michael for your hard work, it was a lot of help anyway!

This implementation doesn't try to support transaction interleaving as required
by the XA spec. Instead, it throws an exception saying it's not supported.

I tested it with the JOnAS application server (after fixing some recovery bugs
in JOnAS itself :), and it seems to be fine with the limitations. It needs
testing with other application servers to see if the limitations matter for
them.

Anyone with access to WebLogic, WebSphere etc: please help! I can send the
simple servlet I used to test JOnAS if you're interested.

BTW: How does the translation work? What strings need to be translated?

- Heikki

Heikki Linnakangas wrote:

> BTW: How does the translation work? What strings need to be translated?

Usually the only user-visible strings are exception messages. For simple
cases, just wrap the string in a call to org.postgresql.util.GT.tr(). If
there are variable parts to the string, use {0} {1} etc and use the
PSQLException ctor that takes separate substitution values. See the
existing code for examples.

-O

Heikki Linnakangas wrote:
> I've been working on the XADataSource implementation. Patch attached.
> Test case is in the separate zip file, because I couldn't get cvs to
> include it in the diff.

This looks good to me. A few comments:

- we'll need to wrap translatable strings in GT.tr() calls
- there are some places where you compare Xids by identity (==) --
shouldn't these be using .equals()?
- do we really need all of that Base64 encoder/decoder class? Seems like
we could get away with something much more simple.

-O

On Mon, 12 Sep 2005, Oliver Jowett wrote:

> Heikki Linnakangas wrote:
>> I've been working on the XADataSource implementation. Patch attached.
>> Test case is in the separate zip file, because I couldn't get cvs to
>> include it in the diff.
>
> This looks good to me. A few comments:
>
> - we'll need to wrap translatable strings in GT.tr() calls

Ok.

> - there are some places where you compare Xids by identity (==) --
> shouldn't these be using .equals()?

Hmm. At those places, the user of the XAResource interface has supplied
both of the Xids being compared, within the same transaction. In
principle, I guess you're right. Nothing in the spec says that it's safe
to assume that the same Xid object is used for start/end/prepare calls.
I would be very surprised if it didn't work in practice, however.

I'll fix it. Premature optimization is not good..

> - do we really need all of that Base64 encoder/decoder class? Seems like
> we could get away with something much more simple.

Yeah, it's bloated for our purposes. I'll strip out all the gzip stuff
etc.

Thanks for your comments.

- Heikki

(Reposting to pgsql-jdbc@postgresql.org, since it haven't shown up yet).

On Mon, 12 Sep 2005, Oliver Jowett wrote:

> Heikki Linnakangas wrote:
>> I've been working on the XADataSource implementation. Patch attached.
>> Test case is in the separate zip file, because I couldn't get cvs to
>> include it in the diff.
>
> This looks good to me. A few comments:
>
> - we'll need to wrap translatable strings in GT.tr() calls
> - there are some places where you compare Xids by identity (==) --
> shouldn't these be using .equals()?
> - do we really need all of that Base64 encoder/decoder class? Seems like
> we could get away with something much more simple.

Ok, I finally got around fixing these.

Updated patch can be found at:

http://users.tkk.fi/hlinnaka/pgsql/twophase_jdbc_20050921.diff

I now also tested it with JBoss. It seems that JBoss does utilise transaction
interleaving by default, which we don't support. However, it can easily be
turned off by setting the "track-connection-by-tx"-parameter in the datasource
configuration. The configuration examples also set it for Oracle, MSSQL and
Facets (what is it, BTW?), so it seems acceptable to me.

- Heikki