JBossDeveloper

This doesn't make any sense.

A TCK test should not require that you need to be able to look up the transaction manager. After all the TCK tests *adherence to the spec*.

Adherence to the spec, must not require AS specific stuff!!

I don't want us adding stuff in our code. Our code should work properly irrespective of whether we are running in JBoss AS.

I suspect the test invalid.

A TCK test should not require that you need to be able to look up the transaction manager. After all the TCK tests *adherence to the spec*.

 

Adherence to the spec, must not require AS specific stuff!!

Before clebert made the initial change to fix the AS test the tck passed fine! However I am not sure that the test is invalid! If you send a message outside of the normal tx boundaries JMS we do throw an exception. Just ti reiterate the test does the following:

1. start a user tx

2. send a message

3. end the tx

4. rolback the tx

5. send a message//this should fail!!

This seems like a valid test to me.

Initially we had a flag that we set on the managed connection to specifu if the session was transacted, we set this flag via the xa resource start/rollback/commit methods. However when you do this the above fails because we have set the xa flag to false at step 4.

Clebert changes this by just setting the flag to false in the cleanup method on the managed transaction so the flag is only reset when the connection is sent to the pool. This has broke the tck.

I am not sure, apart from cleberts current fix, how else we can handle this as.

The bottom line is it makes zero logical sense to have a TCK test requiring non portability in order to pass!

The whole point of the TCK is to make sure the component adheres to the JCA specification. The JCA specification describes a component model for connecting to *any JCA compliant container*, not just JBoss AS.

** So, no tx mgr hacks please. **

Like Andy said, this test used to pass, without requiring any such hacks.

I think now we should go further and just revert the JCA session caching behaviour to how it used to be *before* we decided to cache both XA and non XA sessions.

Can we just change the server side XA behaviour to act as non transacted when the session is not enlisted, like we used to?

I think now we should go further and just revert the JCA session caching behaviour to how it used to be *before* we decided to cache both XA and non XA sessions.

 

Can we just change the server side XA behaviour to act as non transacted when the session is not enlisted, like we used to?

I am not sure I understand the reasons why we added the caching, maybe someone could explain.

Also this test used to pass before we added the caching, maybe a kiss approach is the best option.

Andy Taylor wrote:

 

I am not sure I understand the reasons why we added the caching, maybe someone could explain.

AFAIR we started to hit issues with this use case when we changed the semantic associated to our XA session.

In JBoss Messaging, a XA session was accepting work when there was no TX (JBM 1.4's, SessionAspect#isXAAndConsideredNonTransacted()).

We decided to change this for HornetQ so that our XA implementation was "correct": if the session is XA, no work can be done outside a tx.

However this implied to change HornetQ RA implementation: we now needed a 2nd non-xa session to perform work when the RA was using a XA Connection outside a TX to comply to the JCA spec and pass the TCK.

If I understand tim's suggestion, we'd revert our server code so that a XA session can again perform work outside a TX and get rid of the 2nd non-XA session from our RA.

Andy Taylor wrote:

 

Also this test used to pass before we added the caching, maybe a kiss approach is the best option.

+1

Tim Fox wrote:

 

Andy Taylor wrote:

 

Also this test used to pass before we added the caching, maybe a kiss approach is the best option.

+1

and maybe add a flag and only enable by default when used by the RA?

Jeff, do you know what was changed on server session?

Andy Taylor wrote:

 

Jeff, do you know what was changed on server session?

afaik, main change was for https://jira.jboss.org/browse/HORNETQ-328 (http://fisheye.jboss.org/changelog/Hornetq?cs=8926)

This commit makes sure that no work will be done if the XA session has no enlisted tx.

This solved the tx timeout issue but introduces the issue with the RA.

Everything is passing now because you have hacked it to pass.

It's not a valid fix. Getting a TCK test to pass by putting in non portable assumptions is not right.

The whole point of a JCA adaptor is it should run anywhere.

Let's go back to how it used to work, everything was also passing then anyway.

You're missing the point.

It's absurd to make a **TCK** test pass by adding app server specific hacks.

It should be possible to pass the TCK, without relying on such hacks.

Like I've mentioned twice now, the whole point of JCA is the adaptor should run anywhere!!

Please remove the hacks. We'll roll back to how this used to be done.

To illustrate my point: The TCK should also pass with our RA running in Glassfish.

Clearly your app server hack won't work there.

I think Tims point is that if we ran in an app server that didnt plugin its transaction manager then the test would not pass making us non portable.

So we can either leave cleberts changes in until we have given the eap guys a release or remove them now and the eap guys can wait a while, i'm not sure how long these changes will take having not done them, clebert, Jeff, is this a quick job?