I have an MDB that listens on a queue. Whenever it recieves a message, it will forward execution to a stateless session bean which has a lot of logic, updates etc. Here is the flow of logic/call chain.
queue->mdb->session bean->session bean->email->logging
The end result is an email and subsequent logging.
By default, the MDB transaction is managed by container and its time out is 30 seconds.
However, whenever timeout is reached, it throws timeout exception and retries the message, but the nested transaction and its processes are not rolled back(from session bean). As a result, multiple emails go out because of the retry but all the logging is rolled back (from session beans) EXCEPT for what is logged from the MDB itself
Shouldnt all the transactions being called from the MDB rollback including the mdb logging and especially the emails?
The session beans all have default transaction type as ‘required’.
I also explicitly set the TransactionManagement type as CONTAINER with the TransactionType as REQUIRED. Emails still go out. Logging from session beans rollback but retry occurs.
I then set the TransactionType as REQUIRES_NEW. Emails still go out. Logging from session beans rollback but retry DOESNT occur.
what setting do I put to make sure the ENTIRE transaction started by the MDB and any transactions called from it, get rolled back AND retry occurs?
I do not want to use bean managed transactions because I want the retry on failure to occur.
My application server is weblogic 10.3 with ejb 3 spec.
Your email resource is not transactional, so ditch the mdb timeout and have your email sender rely on the email transport timeout, at which point, call TX setrollback only. The tx will rollback, the message will be redelivered and your email may only be sent on a successful retry. The outcome of email transport timeout may not be deterministic.