Ok,
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)