Hi all,
i have a question concerning transactions and exceptions (and, of course,
orion). Consider having a client C, an entity bean E1 and another one E2.
All functions of the beans have the transaction attribute "Required". Now C
calls a function on E1 which calls another function on E2 which throws an
exception:
C
E1.foo()
<transaction>
<E1.foo_orion_wrapper>
<E1.foo_implementation>
{
try
{
E2.foo()
<E2.foo_orion_wrapper>
<E2.foo_implementation>
{
throw new SomeException();
}
</E2.foo_implementation>
</E2.foo_orion_wrapper>
}
catch (Throwable e)
{
// do something
}
}
</E1.foo_implementation>
</E1.foo_orion_wrapper>
</transaction>
Now the "hundred-points-question": Which will be the resulting control path?
Answer for orion:
The <E2.foo_orion_wrapper> catches the exception (must have everything under
control), marks the transaction for rollback (that's ok) and rethrows the
exception directly to the client C - without giving the catch in
<E1.foo_implementation> any chance to be at least notified that something
went wrong (and that's at least a bit strange).
What would be the answer according to the spec (if any)? For my
understanding, it would be more logical (and predictable) to return to
E1.foo instead, since from the E2 point of view it is the client, who called
it (consider being E2 in a different server within a cluster). OK, the
transaction is marked for rollback and so everything we do will be for the
trashcan, but at least we could generate some better error message for the
client C according to the situation within E1 or other stuff.
Any comments?
Best regards,
Jens Stutte
PS: I did not try this for session beans yet, but i assume that the
behaviour will be the same - if not, one of them must be a bug...
____________________________________________
[EMAIL PROTECTED], http://www.netmedia.de
netmedia GmbH
Neugrabenweg 5-7
66123 Saarbruecken
Germany
fon: +49 (0) 681 - 3 79 88 - 0
fax: +49 (0) 681 -�3 79 88 - 99
