i want the container to handle the transactions. the only way to make this happen is for a and b to throw ejbexception on system failure. my problem was that when b threw the ejbexception, the container was marking the entire transaction for rollback, and i really should not have continued, which caused a whole bunch of problems down the line. since b can be called on its own, it needs to throw an ejbexception to cause the container to rollback. therefore, if a wants to call b but continue if b throws an ejbexception, then b should really be in its own transaction, otherwise a should catch any exception from b and throw ejbexception itself. in retrospect, i see that i was probably misusing the paradigm if anything. that is, a should catch ejbexception and not proceed if this is the case if it wants to call b within the context of a transaction. in my case, i really did want to proceed, which means b should be requiresnew. i think by now i've gotten the answer to my question.
as for the duplicate key, you are right, and we happen to be using oracle for development, but in the interests of being truly vendor neutral, which we need to be, i'd rather not inspect the error messages. regards eric -----Original Message----- From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 17, 2002 6:19 PM To: Eric Kaplan Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-user] inner transactions > thanks for responding on this. seems like my only real choice is > requiresnew, and make > sure that if a really wants to handle the whole thing as one transaction, a > then catches > the ejb exception and throws its own ejb exception to back out the > transaction, thus supporting > a truly nested transaction. b needs to throw an ejb exception in the event > that it is called > on its own and i need a failure to cause the rollback. > this was my suspicion, but it's good to have someone else confirm it. Do you throw the EJBException in b yourself? By the sounds of it, it should be an application exception being thrown if you're saying you want to handle it yourself...? > one question re entity beans, bean managed persistence. does anyone ever > throw DuplicateKeyException? > i mean, this would imply that an ejbCreate always first looks for an > existing entity before storing, > which isn't that efficient. also, why does every ejb lifecycle method have > an exception defined > except for ejbStore? Could you do it via vendor specific stuff? for instance, Oracle's SQL exceptions are (from memory) quite informative... you could pull out the error code and check why the insert failed... cheers dim > > eric > > -----Original Message----- > From: danch [mailto:[EMAIL PROTECTED]] > Sent: Sunday, February 17, 2002 12:27 PM > To: Eric Kaplan > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] inner transactions > > > 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 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
