Hi Russell,
Russell Chan wrote:
I think this can be done by holding back published messages in an own client queue which would be flushed on commit and discarded on rollback.Hi all,
We currently have an xmlblaster client connection implemented in jboss 3.2.6 (publishing only). However, the current usage does not allow us
to tie in the xmlblaster connection as part of a transaction (ie a publish only goes out when the transaction is finally being committed - like a database resource adapter). We currently have issues where a publish will go out, and later in the transaction there is a rollback. We would like the publish only to go out on the final commit of the transaction, and preferably after the database portion of the transactions' resources are committed.
I noticed that there was some work done towards making this work back in 2002 by Peter Antman, but it appears that it applies to older versions of jboss, and it wasn't clear to me if this code has been updated. ( I'm speaking about the k2 related stuff. ) I've managed to get the resource adapter in jboss, but in a non transactional fashion.
great
Has anyone got this working before I expend lots of effort into making this work? Or maybe it's simple and I'm confused, in which case enlightenment will be very welcome! :-)To my knowlege there is no such work done. As I said a client side queue (we have a well tested queing framework) should do it.
Which j2ee interfaces to implement to accomplish that I am not really aware about yet. I would need to have a closer look at the current j2ee standards. Did you have a specific idea about how to solve this by your own ? If you shortly explain it here we could see how to make it fit together ...
Cheers Michele
Regards, Russ Chan [EMAIL PROTECTED]
