-
15. Re: HornetQ RA integration
adrian.brock Mar 19, 2010 10:40 AM (in response to timfox)Tim Fox wrote:
Adrian,
So you're saying it's correct for a JCA impl to call
getManagedConnection()
then
managedConnection.getXAResource()
and then never enlist the resource in a tx, and expect the managed connection to behave as non transacted?
I can't see this requirement in the JCA spec anyway, but I will defer to your better knowledge of JCA.
Why do you think that is a correct assumption?
The managed connections are pooled, so you've got no idea whether the connection is enlisted from one check out of the
connection from the pool to the next unless you track it yourself in the ManagedConnection/XAResource calls.
All your assumption does (including your wrapper workaround) is defer the failure to the case when
for the same ManagedConnection it does:
Request1: Is in a tx so use an XAConnection
Request2: Not in a tx - oops still tries to use an XAConnection for non xa stuff.
That is unless you back the ManagedConnection with two real connections/sessions?
Anyway, although not exactly on topic, I remember arguing about this line in the JCA 1.6 spec review
See 7.10.1 Transaction Scenarios Requirements
"
Note that both
LocalTransaction and XATransaction resource adapters support local
transactions. and they are both referred to as “local transaction capable” resource
adapters in the section below."
We came to conclusion that this statement (from an older version of the spec) says
that you can deploy a rar declared as XATransaction in local-tx mode at the connection factory level.
But it could also be taken to require the behaviour we are discussing?
-
16. Re: HornetQ RA integration
adrian.brock Mar 19, 2010 10:51 AM (in response to timfox)Tim Fox wrote:
If that's not correct, I find it odd. However our impl should work in either case now, since Jeff has created a proxy around the real XAResource which switches between a non transacted and an XA session behind the scenes depending on whether the resource has been enlisted or not.
I guess we could implement that for you with a slight tweak to the TxConnectionManager.
i.e. if you configure
<no-tx-seperate-pools/> - an old workaround for Oracle
on the tx-connection-factory we use the LocalXAResource rather than invoking getXAResource()
when the request is outside a JTA transaction at initial construction of the ManagedConnection,
regardless of whether it says <xa-transaction/>
That way you'll have two seperate pools for the different types of requests.
In one pool getXAResource() will have been invoked, in the other it won't.
Of course, other JCA implementations probably don't have that feature,
so you'll still have problems with them. ;-)
-
17. Re: HornetQ RA integration
timfox Mar 19, 2010 1:35 PM (in response to adrian.brock)Adrian Brock wrote:
Why do you think that is a correct assumption?
The managed connections are pooled, so you've got no idea whether the connection is enlisted from one check out of the
connection from the pool to the next unless you track it yourself in the ManagedConnection/XAResource calls.
All your assumption does (including your wrapper workaround) is defer the failure to the case when
for the same ManagedConnection it does:
Request1: Is in a tx so use an XAConnection
Request2: Not in a tx - oops still tries to use an XAConnection for non xa stuff.
That is unless you back the ManagedConnection with two real connections/sessions?
Yeah, that's the plan. E.g. ManagedConnection potentially maintains two refs - one to a non transacted session and one to an XA session.
Personally I don't like the idea of an XA session behaving as non transacted when not enlisted. To me either it's an XA session or not.
I'm thinking - do other XA capable EIS XA connections default to non transacted when not enlisted? My hunch is no, since this doesn't seem to be mandated anywhere, and some (e.g. databases) XA functionality probably existed long before JCA.
If that's the case, some kind of jiggery pokery like we're doing with maintaining two refs, is probably done by them inside their own JCA adaptors in order to satisfy the semantics that JCA expects.
-
18. Re: HornetQ RA integration
jmesnil Apr 1, 2010 5:35 AM (in response to timfox)One more question about HornetQ RA,
We argued with tim on the number of session we must keep in our ManagedConnection to handle all use cases (esp. doing JMS work using a non-enlisted XA Session).
Currently, we have 2 sessions:
- 1 XA Session
- 1 regular JMS session which is transacted or not depending on the ConnectionRequestInfo
Tim argues that we need 3 sessions:
- 1 XA Session (to be used when doing work in a enlisted XA tx)
- 1 transacted session (to be used when doing work in a local tx)
- 1 non-transacted session (to be used when doing work from a XA Resource which is not enlisted)
What do you think about this?
Does the connection pool should have partitioned the managed connections based on their transaction types (and 2 sessions are ok)
or should we have 3 sessions and return the correct one ourselves?
-
19. Re: HornetQ RA integration
timfox Apr 1, 2010 5:40 AM (in response to jmesnil)To clarify, this is the problem we have.
AS gets a managed connection and calls getLocalTransaction(), this results internally in the RA creating a transacted local session.
The user does work with that connection, then finished, it gets returned to the pool.
Next user wants an XA connection, AS gets the same cached managed connection, getXAResource is called, but the resource is never enlisted in a tx.
This causes us to use the local transacted session we cached earlier on the connection, but it's transacted, and the behaviour we require is an XA session behaves as non transacted non XA session when not enlisted.
-
20. Re: HornetQ RA integration
jesper.pedersen Apr 20, 2010 2:58 PM (in response to timfox)You are looking for the case where the ManagedConnection is used in a LocalTransaction, then put back into the pool, then retrieved but not enlisted in a transaction, correct ?
The comments in
org.jboss.resource.adapter.jms.JmsManagedConnection
provides some insight to this case inside an application server:
* <p>From the JMS tutorial: * "When you create a session in an enterprise bean, the container ignores * the arguments you specify, because it manages all transactional * properties for enterprise beans." * * <p>And further: * "You do not specify a message acknowledgment mode when you create a * message-driven bean that uses container-managed transactions. The * container handles acknowledgment automatically."
So the above case would be out-of-scope.
-
21. Re: HornetQ RA integration
timfox Apr 21, 2010 5:48 AM (in response to jesper.pedersen)Jesper, I don't follow the connection between the question we are posing at the spec. excerpt that you cite. Can you elaborate?
Let me summarise the problem again, it's in two parts:
We're considering the case, where a managed connection has been used as part of a local transaction, then that's completed and it's returned to the pool.
The same connection is then retrieved from the pool, getXAResource is called, but it's not enlisted in any JTA tx.
The user then sends some messages using this connection. (There is actually a TCK test that tests this)
How should that connection behave?
According to the previous discussion it should behave as a non transacted session, however that was for the case when the connection was previously used as part of another JTA tx, in this case the connection has been used as part of a local tx.
In this case should the connection also act as a non transacted session, like in the XA case?
-
22. Re: HornetQ RA integration
jesper.pedersen Apr 21, 2010 9:26 AM (in response to timfox)We're considering the case, where a managed connection has been used as part of a local transaction, then that's completed and it's returned to the pool.
In this the managed connection should reset to its default state through the ManagedConnection.close() method. See 7.10 in JCA 1.6.
The same connection is then retrieved from the pool, getXAResource is called, but it's not enlisted in any JTA tx.
The user then sends some messages using this connection. (There is actually a TCK test that tests this)
How should that connection behave?
A transactional resource adapter used outside of a transaction must behave as auto-commit = true. See 7.15.1.1 in JCA 1.6.
According to the previous discussion it should behave as a non transacted session, however that was for the case when the connection was previously used as part of another JTA tx, in this case the connection has been used as part of a local tx.
Could you expand on this "previously used" case ?