On 27 May 00, at 18:37, Aaron Mulder wrote:
> Currently, if there's a SQLException generated, it seems to fall
> right out of the server and get passed back to the client. This doesn't
> seem like the right behavior - shouldn't the container intercept the
> exception so it can take some cleanup actions? What would happen to the
> stateless session instance and transaction and stuff? But perhaps it is
> doing so and rethrowing the original exception - it just seems like there
> would be a different stack trace in that case.
>
> But assuming the container is doing the right thing, how should
Hi Aaron,
I doubt the container is doing the right thing at this point on
exceptions. (I'm guessing without thinking too hard, but I feel
pretty sure...) You should look at chapter 12 of the EJB 1.1 spec
for the correct behavior with regard to exceptions. Basically, there
are two kinds: an application exception, for which you should try to
commit the transaction on a boundary unless it has been marked
for rollback only; and system exceptions, for which the transaction
should always be rolled back and we are responsible for cleanup of
any resource we can.
By the way, the Enterprise JavaBeans specification is actually a
well-written and easy-to-understand document of moderate length.
I don't think the average bean developer needs to read it, but I think
the average container developer should. :-)
Also, I wanted to say that it sounds like you're getting up to speed
quickly on this project. I can't wait to see what you come up with
for the connection pools, which as Marc mentioned are really a key
piece of the container.
-Dan
> the DB pool behave? The connection needs to be returned to the pool.
> Presumably, I need to delistResource on the transaction with the code for
> failure. But will the Transaction follow up by calling rollback() or
> forget() on the XAResource? This is critical for the 1.0 JDBC wrappers -
> I need to know whether to rollback and return the underlying connection to
> the pool immediately or wait for the rollback() signal to do it.
>
> Thanks,
> Aaron
>
>