You call that a spec of "moderate" length? Before long it's going
to be more cost-effective for me to buy a duplex unit than to burn through
more reams of paper... ;)
Anyway, it looks like if there is a current Transaction, the
SQLException should be propagated to the Container, which should then
commit or rollback the transaction. In either case, with a JDBC 2.0
driver the connection should be returned to the pool. With the JDBC 1.0
wrapper, the connection should be returned to the pool if there is no
Transaction, and held pending commit or rollback if there is a
Transaction.
So what if the SQLException happens *during* a commit or rollback?
I would think in this case we probably want to assume that the connection
is permanently damaged and take it out of the pool altogether. Perhaps
that's only true for the 1.0 wrappers. But I have to think that if you,
say, lost your network connection to the DB, it would cause an exception
during normal operation. Then you'd try to rollback, and get another
exception. So I think we want to assume that an error during rollback
means a connection is *dead*, and probably the same for a commit.
I guess this is only a problem for the 1.0 wrappers. In the case
of a true JDBC 2 driver, we never call commit or rollback on the
Connection - rather, the TransactionManager calls it on the XAResource, so
we're not really sure which XAConnections should be (or can safely be)
closed. Even if you can get an XAConnection from the XAResource (given
the 1 to 1 mapping), it may already be in use by another client, etc.
Aaron
On Sun, 28 May 2000, Aaron Mulder wrote:
> On Sat, 27 May 2000, Dan OConnor wrote:
> > 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. :-)
>
> Sigh. This brings the Spec Count to 5... I'm sure you're right.
> I'll check it out.
