In the case of an EJB with BMT, when a non application exception occurs during transaction execution (an OutOfMemoryError or any RuntineException for instance), the transaction is marked for rollback (as specified by the spec) but is not actually rolled back. As the bean instance is then discarded, there is no way to access the transaction context for the client to perform the rollback. The transaction thus remains as it this.

When the transaction manager finally marks this transaction for timeout, it does not perform a rollback either. From the database point of view, all this ends up in an in progress transaction which is neither commited nor rolled back and keeps database locks, holding resources and blocking operations for other threads trying to access the same data.

The EJB specification does not prescribe any particuliar behaviour except the marking of the transaction for rollback and the discard of the EJB. But the transaction should also be roll backed at some point in time (immediately I would say). For instance, in a Weblogic environment, the transaction is immediately rolled back after the exception has been intercepted by the container.