JCA with JBoss 3.0

[padams]

I'm writing a connector for the company I work for. My connector was working great when deployed under JBoss 2.4.4. I recently upgraded to 3.0 and have been having a lot of troubles.

Particularly I'm getting an exception when creating a new connection with a null Subject and an instance of javax.resource.cci.ConnectionSpec.

The app server calls ManagedConnection.matchManagedConnections with a connection set, null subject and an instance of my connection request info object. My matchManagedConnections method does not find an appropriate match and so returns null. From the application server I then get an exception like:

Error in use of ManagedConnectionPool: matchManagedConnection failed with subject: null and ConnectionRequestInfo: pea:*****

(pea:***** is the result of my ConnectionRequestInfo object over-riding toString).

I'm assuming this exception is the result of my matchManagedConnection method returning null but reading the connection spec it states that if no suitable match is found in the set of connections given it that it can return null, in which case the app server should create a new connection.

Has anyone else run into something similar?

Also, my connector is deployed with LocalTransaction support only. I'm running into a situation where an interaction execution results in an exception being thrown (EIS specific, what I was testing) and the application server attempts to roll back a transaction that it never started (which of course fails). This particilar connection/interaction is being initiated from a session EJB method that is deployed stating no transaction support (<trans-attribute>NotSupported</trans-attribute> in ejb-jar.xml)..

Again has anyone run into this problem?

Thanks.

[davidjencks]

1. MatchManagedConnection problem. You have to match your PoolingStrategy policy to the credentials available and your adapters matching strategy. If you are using application managed security (only) you should use ByApplication or ByContainerAndApplication. I think there are some concurrency problems if the ConnectionManager gives a large set of ManagedConnections to be matched, so I've made it so it only gives one connection selected so it should match. You have to set the criteria in the PoolingStrategy. I should probably change the examples to always use ByContainerAndApplication since the others are likely to give only slight speed advantages. This should work if your matching strategy is based on equality of subject and ConnectionRequestInfo. If it is based on something else, tell me how it works.

2. This is a bug I think. Can you supply a little more info on the error (does it result in ConnectionErrorOccurred being called on the ConnectionEventListener) and a log/stack trace with logging set to trace? Please file a bug report on sourceforge.

[padams]

Changing to use ByApplication fixed my problem. I tried to use ByContainerAndApplication and this didn't work. JBoss complained about requiring a non-null subject then. I would have supplied some principal mapping properties but I didn't find any examples that showed how to do this similar to those in previous releases. It almost seems that the default should be ByContainerAndApplication and that this should not complain about null subjects or application specific connection info.

For the rollback w/out begin I submitted a bug on sourceforge. Yes my connector does call connectionErrorOccurred on the ConnectionEventListener (with ConnectionEvent.CONNECTION_ERROR_OCCURRED and the exception). For the bug report I tried to enable TRACE mode (in log4j.properties) but it didn't seem to give me any more output so I supplied what I could.

I recently ran into one other strange end case where a transaction begin happens successfully, all interactions within the transaction execute succefully but the commit causes an exception (an EIS specific bug). The app server prints the exception stack trace from the commit failure but never calls rollback...

Thanks for the help.

[padams]

Yet another problem. While debugging some of the EIS side code this morning I ran into a situation where the being transaction failed. This failure was never reported to the client (EJB) and the interactions that were meant to be part of the enclosing transaction were still executed. When it was all over commit was called (which also failed)....

Seems to me that container managed transactions worked better in JBoss 2.4.4

[davidjencks]

I think the "commit failure does not result in rollback being called" is correct behavior for a local tx adapter and the app server. By the time commit is called, the tm has already called prepare, and everyone in the tx voted that commit was ok. The only exceptions that can occur at this point are on the level of "system errors", there is no way for a tx participant to affect the outcome of the tx.

If you have only one tx participant this is not a problem, your work presumably did not get committed. If you have more than one participant, jta does not supply any way to end up with a consistent result. You may be able to figure out something with compensating transactions. If you have more than one participant you should have seen a warning "you are not getting the semantics you expect"

If your app is not notified that commit failure occurred, that is a problem.

[padams]

This doesn't seem correct to me. My EIS does not support two phase commit and as a result my adapter only declares Local Transactional support. So there is no concept of "prepare" and a failure to commit would seem to constitute a failure of the entire transaction. In this case a rollback seems appropriate to me.

Looking at the connector spec and related documentation I haven't found a discussion of this scenario.

I can concede that interactions like begin/commit/rollback should be concrete enough as not to fail outside of some catastrophe. Mine only failed due to a development version of our EIS have class inconsistencies. The EIS should automatically rollback an exception that doesn't get commited following some logical timeout. SO despite the fact that I'd like a rollback I can understand where you're coming from.

The failure to commit however was not reported to my client so I've submited sourceforge bug id 575966.

Thanks.

[davidjencks]

I think there are 2 issues here:

1. JBoss is not telling your application something went wrong. This is definitely a problem, I will look into it, thanks for the bug report.

2. How should local transactions relate to the tm? The spec indicates that the tm is not responsible for consistent results when trying to manage more than one transactional resource in one jta transaction if at least one of the transactional resources only supports local tx. In principle, you can't using only the xa protocols. So, I figured the best we can do is ignore the prepare step and try to commit on commit. If your EIS throws an exception during commit, I hope it is written well enough to effectively rollback the work it is declining to commit. However, by the time it is asked to commit, the tm has to assume that commit will succeed. It can't call rollback later: commit ends the tx, no matter what the outcome.

[padams]

I'm fine with 2. Our EIS does in fact deal properly with the failure to commit not applying changes made during the transaction.

Thanks.

[bruces]

My adapter currently has this problem, too. My LocalTransaction implementation doesn't roll back the transaction if commit fails. Commit can easily fail due to write-write conflicts in a transaction that hasn't been prepared, and LT has no prepare. This is very similar to commitOnePhase in XA processing. My XA resource does roll back the transaction on commit failure in commitOnePhase, so I guess I should change my LT to do the same.