Ws-Tx bridge creates JTA transaction, cannot join?

[ruthbd]

It appears that the ws-tx bridge, as currently written, needs to start before anything else in the thread sets up a JTA transaction. Is it a technical limitation that the bridge needs to be "first", or just a limitation of the bridge code as its currently written? I have just noticed that I need to be mindful of where the bridge is initiated, with respect to the spring-tx demarcation, otherwise I get an exception indicating that a transaction already exists.

Thanks,
Brice

[jhalliday]

That's by design. Best bet is to hook it into the WS interceptor chain so your application code does not need to bother about it.

[ruthbd]

Yep, that's what we do on the service side, (for incoming connections) but on the client side, we are also bridging our outgoing service calls to our local JTA transaction. What I've done now is create an Interceptor that I wire in with Spring, but I found I have to be careful of the order, because the same bean can (is) surrounded by the Spring standard transaction advice for Hibernate, and that currently needs to execute *after* the bridge is started.

I think when Paul R. was here working with us (back in October '07) to get the ws-tx and bridging to work, you had mentioned that client-side bridging was not originally intended for the bridge code (but, we got it to work, and its working fabulously so far).

Thanks for the quick response!

[jhalliday]

The way to think about this is: the JTA transaction needs to be subservient to the WS-AT transaction. When e.g. an EJB container starts a new JTA transaction, it's always top level rather than subservient. Only the bridge creates the JTA transaction in the right way for this usage scenario. Hence it has to come before any interceptors that check for a running transaction and start a new one if necessary.

This is unfortunately a bit of a configuration nightmare, particularly with e.g. EJBs exposed as Web Services using @WebService. It would be nice if there were a way to take an existing top level JTA transaction and transform it into a subservient one, but there isn't.

[ruthbd]

"jhalliday" wrote:
The way to think about this is: the JTA transaction needs to be subservient to the WS-AT transaction. When e.g. an EJB container starts a new JTA transaction, it's always top level rather than subservient. Only the bridge creates the JTA transaction in the right way for this usage scenario. Hence it has to come before any interceptors that check for a running transaction and start a new one if necessary.

This is unfortunately a bit of a configuration nightmare, particularly with e.g. EJBs exposed as Web Services using @WebService. It would be nice if there were a way to take an existing top level JTA transaction and transform it into a subservient one, but there isn't.

Alright. We'll categorize this under "technical limitation" :-) We'll just need to make sure Mark includes "subservient" transaction coersion in the next version of the JTA spec ;-)

[jhalliday]

JTA does not really have any notion of subtransactions, largely because no major XA Resource manager supports them. If I has an infinite amount of free time I'd like to put subtransaction support into one of the pure java embedded databases, such as hsqldb. But first we need subtransactions in XTS, so that we can write the reverse direction of the bridging...

[ruthbd]

"jhalliday" wrote:
JTA does not really have any notion of subtransactions, largely because no major XA Resource manager supports them. If I has an infinite amount of free time I'd like to put subtransaction support into one of the pure java embedded databases, such as hsqldb. But first we need subtransactions in XTS, so that we can write the reverse direction of the bridging...

What would subtransactions provide in XTS? I'm not sure I follow that. That's something different from having nested coordinators, obviously (since that's provided today). Would subtransactions be the ability for a WS-AT to be a part of a parent Tx (such as a JTA Tx)? Right now the bridge sets up the WS-AT and makes the JTA a participant of it, right?

[marklittle]

Subtransactions == nested transactions (Eliot Moss, 1981).

"nested coordinator" is more accurately interposition of coordinators. Check out the OTS specification (circa 1992).

[ruthbd]

Subtransactions == nested transactions (Eliot Moss, 1981).

"nested coordinator" is more accurately interposition of coordinators. Check out the OTS specification (circa 1992).

Ah, correct. See, its been like 9 months since Paul R.'s training session and the cobwebs are starting to set in ;-)