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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org