-------------------------------------------- If a message-driven bean instance starts a transaction in the onMessage method, it must commit the transaction before the onMessage method returns. The Container must detect the case in which a transaction was started, but not completed, in the onMessage method, and handle it as follows: � Log this as an application error to alert the system administrator. � Roll back the started transaction. � Discard the instance of the message-driven bean. -------------------------------------------------
So Does this means that if a BMT message driven bean throw a system exception, the container will roll back the transaction.
-------------------------------------------- If a message-driven bean instance starts a transaction in the onMessage method, it must commit the transaction before the onMessage method returns. The Container must detect the case in which a transaction was started, but not completed, in the onMessage method, and handle it as follows: � Log this as an application error to alert the system administrator. � Roll back the started transaction. � Discard the instance of the message-driven bean. -------------------------------------------------
So Does this means that if a BMT message driven bean throw a system exception, the container will roll back the transaction.
Container will rollback transaction when bean instance throws a system (non-application) excetion.
Please refer to what Specs says on page 374:
Bean Provider can rely on the Container to perform the following tasks when catching a non-application exception: � The transaction in which the bean method participated will be rolled back.
You have to look at Table 18 on page 378 of the spec. When a BMT message-driven bean throws a system exception the container must take the following actions:
Log the exception or error.
Mark for rollback a transaction that has been started, but not yet completed, by the instance.
Discard instance.
Remember that in BMT beans the Bean provider is responsible for demarcating the transactions, and thus, the container does not get to start and or commit the transactions. However, it must call setRollbackOnly on user transactions that have not yet been completed in case a system exception is thrown.
yes, the spec said that. but I just don't understand, BMT MDB has no client view, if mdb call some entity bean and make some changes, and it throw out the system exception, the container just mark the tx for rollback, then who will do the rollback work, if nobody rollback the transaction, then why mark for rollback. The container will discard the instance sooner or later.
Typically, the container instructs the transaction manager to mark the transaction for rollback. The tx is then rolled back. This is needed even for a BMT message-driven bean which has started a tx, because database integrity must be maintained in the event of a system exception being thrown by the bean.
So, does this means, "container marks the transaction for rollback" and "container rollback the container-started transaction" are the same.. ??? If so, then why does the contaienr just marks it for rollback rather that doing the rollback itself ???
Post by:autobot
"How many licks ..." - I think all of this dog's research starts with these words. Tasty tiny ad:
a bit of art, as a gift, the permaculture playing cards