Eric Kaplan wrote: > I have two session beans, a and b. Both are container managed transactions, > Requires transaction. I call a from the client, which presumably initiates > the transaction, and a calls b. Something happens in b, which then throws > an EJBException. It seems like this is initiating a rollback, since b is in > a's transaction. Is this the case? If it is, presumably there is no way to > continue in a at this point, since the transaction has been rolled back?
That's correct. J2EE doesn't support true nested transactions. Since both of the methods are marked Requires, the initial call to a creates the transaction, which is simply propogated on to b when b is called. There are two things you can consider doing: 1. If the exception that happens in b is really recoverable, catch it and throw an application defined exception. This will not trigger a rollback, and will allow a to catch the application exception and recover. 2. You could mark that method of b as RequiresNew, which will cause the container to create a new transaction when b's method is called. This will be a completely separate transaction, _not_ a nested transaction. In other words, it can commit even if the transaction in a rolls back! The only place I've really used this is for key-generation beans, where it really doesn't matter if there are unused numbers in a sequence and I need the critical section kept short. hope this helped, danch _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
