On Wed, 27 Sep 2000, Rickard Oberg wrote:
> Well... we just spent a couple of hours tracing an XAException that was due
> to one of Marc's test beans getting a connection in setEntityContext and not
> closing it... go figure... bad code practice, yes, but could happen.
I'm sorry. Did you just say you spent a couple hours tracing down
a database connection leak in Marc's code? And you want to *remove* the
only indication that the code was leaking connections? Do you have any
idea how long it takes to track down database connection leaks without
such an indicator?
> I don't know about the PS and RS. If we only allow Connection's to be
> "longlived" then it's easy: let all Connection methods either
> a) no tx running -> get a connection from pool
> b) tx running -> get a con. from tx/con mapping, or get a new one if no con.
> has been used within this tx.
> That way at least the Connection object can be held by the bean as much as
> it wants to: it won't use a real connection until it actually does
> something, and even then the underlying connection is returned to pool on tx
> commit.
Look, we're going to have to do it in the S and PS and RS and CS
too. If you buy the argument that stupid things should be allowed, then
we shouldn't distinguish between degrees of stupidity.
> Come on Aaron, that is really not a big deal. Either generate that code
> (trivial) or copy/paste for all methods, or refactor so each method calls
> validateConnection() on each call (or something like that). Having to write
> that code is not an issue.
I'm not complaining that I can't cut and paste. But this is a lot
of damn overhead! Plus extra classes (we don't currently distinguish
between transaction and non-transactional JDBC wrappers).
> As has been pointed out by others, this is actually allowed coding. Plus, it
> makes sure that the amount of time we actually have a connection outside of
> a pool is minimal. Plus, if we get connection and then an exception is
> thrown, the server doesn't die since the underlying connection is not
> tightly bound to the connection object that the bean is (still) holding on
> to.
Well sure, now the connections are bouncing in and out of the
pools like kangaroos! Plus we're doing stuff on every method call. So
much for performance!
Look, think about this: you have to acquire the connection on
every Connection call. You want to close it whenever an S, PS, RS, CS, or
DBMD closes, unless there's another S, PS, RS, CS, or DBMD open. This
only helps if the Connection is stored but the S, PS, RS, or CS is not
stored. This really screws you up if you're counting on calls to
setCatalog, setReadOnly, setTransactionIsolation, or setTypeMap. Sure
that's unlikely, but it's allowed, and this whole bloody thing is unlikely
but allowed.
Okay, now, you don't need to check whether the connection is live
within a S, RS, PS, or CS, since if it wasn't live then your current
object isn't live. But you *do* have to look up the TM and compare your
existing transaction to the current transaction on every method that
writes to the DB, enlisting or delisting as appropriate. There's a lot of
refactoring here - the connection wrappers aren't aware of transactions at
all - that's all done in the factory that gets a Connection from an
XAConnection.
I think you're saving bad coders from having database problems in
exchange for making simple operations slower for everyone!
And all of this - all of it - is only if your DB vendor hasn't
implemented their part of the J2EE spec (in which case our wrappers are
never used).
Aaron
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
