Resource adapter transaction timeout enforcement

[dmlloyd]

I'm working on the Remoting 3 implementation of XAResource and I'm trying to figure out if transaction timeouts are better enforced on the local or remote side. With JCA resource adapters, are the transaction timeouts typically enforced by the resource adapter (I assume using the Timer stuff), or is it standard practice to have the actual resource itself manage the timeout (the database or whatever you're connecting to)?

Basically I'm trying to come up with any reason that the resource adapter would not just deal with timeouts itself.

[weston.price]

It varies and there are no hard and fast rules. Typically the adapter takes care of this if the timeout is required beyond the default, but again, this is not a strict requirement.

[adrian.brock]

For a general XAResource you should do both.
There should be a real (local) timeout in the backend and frontend timeout to cover
network splits, etc.

My question is why are you using an XAResource for remoting?
What state do you have to persist during prepare?
Do you really need to vote in 2PC?

If you have no state and therefore don't need to recover or vote
then you should use a TransactionSynchronization instead.

[dmlloyd]

For a general XAResource you should do both.
There should be a real (local) timeout in the backend and frontend timeout to cover network splits, etc.

Ok, that makes sense.

My question is why are you using an XAResource for remoting? What state do you have to persist during prepare? Do you really need to vote in 2PC?

Remoting has no state, or direct awareness of transactions. However, whatever service you're connecting to by way of Remoting may (and probably does). The reason Remoting 3 has this capability is so that there's a single standard way to propagate transaction state between endpoints - whether it's a database to an app server, two app servers together, or two client applications that don't even know anything about JTA or JCA or anything like that.

[adrian.brock]

Remoting has no state, or direct awareness of transactions. However, whatever service you're connecting to by way of Remoting may (and probably does). The reason Remoting 3 has this capability is so that there's a single standard way to propagate transaction state between endpoints - whether it's a database to an app server, two app servers together, or two client applications that don't even know anything about JTA or JCA or anything like that.

I don't understand. Unless I've misunderstand your requirement.

What you describe is called OTS/JTS. It's already a standard
and is probably a lot more complicated than you've envisoned to do correctly
and efficiently. :-)

There's also already an implementation of JTS that uses remoting in JBoss5 - see the
transaction project, but we are dropping it in favour of JBoss JTS (which should be augmented with a version that runs over remoting rather than just RMI/IIOP).

There's also some overlap with transactional webservices.

You need to speak to the transaction team and make sure you are on the same page.

[dmlloyd]

What you describe is called OTS/JTS. It's already a standard and is probably a lot more complicated than you've envisoned to do correctly and efficiently. :-)

It's possible. It wouldn't be the first time I've overestimated my own cleverness.

You need to speak to the transaction team and make sure you are on the same page.

I intend to do so, and I hope that I will have that chance next week.