I'm observing unexpected behaviour when code that is (transparently) bracketed by a j2ee transaction throws an exception. I would have expected that eventually there would be a call to J2EETransactionImpl#abort(), however it seems instead that J2EETransactionImpl#commit() is called. While this happens infrequently in my case, when it does happen (e.g. an NPE in my application code), it means a write of corrupted data. Is there a way to be certain that the container calls abort() rather than commit()? In case it matters, in my EJBBean, I catch any exception and throw another (custom) exception as in:
/**
* @ejb:interface-method
*/
public void commitFoo(Foo serialFoo)
throws MyFooException {
try {
log.debug("commitFoo() called");
// now modify persistent classes using
// serialized input serialFoo: possible NPE
getFooServer().commitFoo(serialFoo);
// commit() should occur now
}
catch (Exception e) {
log.error("commitFoo() failed", e);
throw new MyFooException(e.getMessage());
// why does a commit() rather than an abort()
// occur now?
}
}I've left responsibility for transactions to the container so I've not thought about these details before.
Configuration: ojb-1.0.rc4, jboss 3.0.6, oracle 8.1.7
Any clues would be much appreciated,
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
