A missed a crtical word: "not": "...In MTS, exceptions do make the container to rollback the transaction..." should be "... In MTS, exceptions do not make the container rollback the transaction...". I used MTS/J++ some years before I started to design EJB applications. In MTS, exceptions do not make the container to rollback the transaction (although it is configurable in COM+ Transaction Service). Symetrically, a successful execution does not commit the transaction. I was always very frustrated about this, since I experienced that it forced me to have a facade component, that took the decision to rollback. I experienced two problems with this: 1) The Facade never added any value. In 100% of the client interactions (client to the container), I wanted a rollback on exceptions. 2) As a client (outside of the container) I could never use the components out of the box. I was forced to have a facade for every component, to be able to complete the transaction (commit or rollback). I know one could argue that a client-mapped facade is a good design, even without regarding transaction completion/exceptions. But I do not think it motivates the behaviour. So, I was very happy when I read the EJB 1.0 spec . It stated that commit/rollback logic is bundled with the concept of container managed transaction demarcation. No appl. exception: Container commits. Application Exception: Container forces a rollback. Just what I need in 100% of the situations I have came across so far. If I need a more fine grained control, I can step down to bean managed transactions. Unfortunately, this was changed in the 1.1 spec. Although, I could escape by using runtime exceptions, wich would give the same commit/rollback behaviour in 1.1 as using application exceptions in 1.0. But for many reasons, I do not like that. The client's view of remote exceptions is not standardized in such a detail that I can have a portable strategi for how to obtain the underlaying runtime exception. Further, a remote exception is modeled for reporting technical problems rather than application defined problems. So far, no question stated :-) Here they come: 1) Whar was the rational behind the change of behaviour in the 1.1. spec? 2) Is there a best practice for handling exceptions and commit/rollback? Always commit on exception, or sometimes view exceptions as another kind of return value / status report independent of transactions? Or throw EJBExceptions instead of application exceptions? /Johan =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
