How do you connect?
Do you use a connection out of JBoss connection pool?
If you use plain JDBC, JDBC-connection-parameter and connection handling within the MDB, the DB access will be commited directly after the SQL-statement.
This is without respect whether the MDB call is successful or not (and might not what you want).
If you have to use plain JDBC, use a DataSource and set the MDB CMT to REQUIRED.
In this case the action is only commited if the MDB return without an exception.
Thanks for your reply.
The actual setup is somewhat more complex than my example.
I reality my MDB need to use JDBC for queries on a number of tables that are not entities and where it makes no sense to define entity objects for these tables.
The JDBC connection I get from a DS.
My MDB also operates on entity objects, naturally through the entityManager.
Everywhere I read about transactions I run into roughly the same text, following taken from:
You should not invoke any method that might interfere with the transaction boundaries set by the container. The list of prohibited methods follows:
Since I basically work with a MDB with CMT I wonder about the consequences of mixing JDBC with CMT.
It is not an option to have the MDB's transaction control the completion of the JDBC queries as their completion is a precondition for making the queries on the entity objects.
I've taken the consequence of not finding any satisfying answers as to why it cannot be mixed and put all of my JDBC in a BMT SLSB with AutoCommit = true and where I open and (naturally) close connection, statements and ResultSets.
Again.....nowhere I've been able to find a decent explanation as to why?
Thanks again. Best regards
Mads M Andersen
if you are using a DataSource and set explicit autocommit the result after return connection into the pool might be surprisingly because the connection will be reused.
We have some trouble in the past with 'non standard' solutions, it will become difficult in case of app-server upgrade or code changes.
But if I understand your scenario correct you do only some SELECTs vie JDBC, right?
If so, there is no necessity for autocommit.
I use JDBC also within CMT beans, I'll leave the connection unchanged and delegate the rollback to the container.
If a RuntimeException is thrown the container rollback for you.
If an Exception should thrown I force the rollback via <context>.setRollbackOnly()
So I prefere a transactional MDB and throw an Exception to rollback or delegate to a SLSB with Tx=RequiresNew.
Remember that all entity access must have a transaction, if no available the container will open one explicit (this can cause less performance)
I'm not only making selects I also do inserts. And it is essential to the application that these inserts have been committed before the application begins to operate on the entities. That's the reason for the AutoCommit.
Mads M Andersen
If the preparation must be done and committed nevertheless whether the Entity access succeeds or not I'll use a SLSB with Tx=RequiresNew for the JDBC access.
If the Entity manipulation failed after this it is a business logic decision to re-queue the message or not.