My problem centers around afterCompletion method in Toplink class AbstractSynchronizationListener which is called from TxCapsule. In this method Toplink is checking the status of the transaction to insure that it is committed, then calling a unitOfWork.getParent().afterJTSTransactionCommit(). In this method they are calling close on org.jboss.resource.adapter.jdbc.WrappedConnection. This is throwing an IllegalStateException stating that it is already committed. Unfortunately unless you put JBoss in trace mode you never have any clue that something when wrong, it eats the exception, not even logging it. The code for finally merging object changes that have been made to the Object, and committed to the database, into the cache is done after the call to the above method. Because that method throws an exception the merge into the cache never occurs. So you end up with the changes in the database, but not in the cache. The next time you ask for the changed object you get back the original from cache. so I have questions obviously, because I have continually watch the problems with TopLink and JBoss move. Anyway, it appears that JBoss does not expect exceptions from the beforeCompletion and afterCompletion calls. Is that correct? Toplink does most of the database activity happens in the beforeCompletion method and that is where exceptions will occur. Second the cache update occurs in the afterCompletion method. So the questions:
1. Is it reasonable to expect exceptions from beforeCompletion and afterCompletion?
2. Should Toplink be trying to call close on WrappedConnection in the afterCompletion, when the transaction status is committed or is that a no no?
3. In the off chance that there is a problem shouldn't JBoss alteast notify by logging the consumer that there is a problem?
Thanks in advance.
Mike H Sr.
PS. Please no comments that we should move to JBoss 3.2.1. I am working on that but will take a while, because we have Axis changes and as well as other changes that have made that difficult and a slot process.
