I'm not sure if this question adds a new perspective to previous
discussions. Pointers back in the archives are much appreciated...
I used MTS/J++ some years before I started to design EJB applications. In
MTS, exceptions do make the container to rollback the transaction (although
it is configurable in COM+ Transaction Service). I was always very
frustrated about this, since I experineced 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 face for every component, to be able
to complete the transaction (commit or rollback).
I know there are reasons to argue that a client-mapped facade is a good
design, even without transaction completion as a driver. But I do not think
this 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 based
transaction demarcation. No appl. exception: Commit. Application Exception:
Rollback. Just what I need in 100% of the situations I have come across
sofar. 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 application exceptions did in 1.0. But for many reasons, I do not
like that. The client's view of runtime exceptions is not standardized in a
way that I can use it in a portable way (when it comes to dig up the
original 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) Is there anyone out there that views the change from 1.0 to 1.1 as a step
forward?
2) Is there a best practice? Always commit on exception, or utilize
exceptions as a nother kind of return value / status report independent of
transactions. Or use runtime 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".
