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
---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
Oliver Jowett 28 August 2005 14:39:23 [ permanent link ]
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
---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
Oliver Jowett 12 September 2005 06:00:59 [ permanent link ]
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
Heikki Linnakangas 13 September 2005 00:43:08 [ permanent link ]
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?
Heikki Linnakangas 29 September 2005 20:43:29 [ permanent link ]
(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.
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
---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
