Hey
> 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?
Yup.
> And you want to *remove* the
> only indication that the code was leaking connections?
Yes, because although it was bad practice it *was* valid code...
> Do you have any
> idea how long it takes to track down database connection leaks without
> such an indicator?
All I'm saying is that the specs allow it, and it *is* possible to deal with
this properly as outlined earlier, and it might even make things simpler
since we don't rely at all on the developer to be nice.
> > 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.
True, although the C stupidity is more "endorsed" by specs than the S PS RS
and CS 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).
It's not a lot of overhead in terms of CPU time (close to zero compared with
the actual JDBC calls), and the tx/non-tx stuff is simply an "if", not
different classes.
> > 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!
Which is safe and less resource intensive (= connections are only used at
the very last moment).
> Plus we're doing stuff on every method call. So
> much for performance!
Aaron, in terms of CPU overhead this is close to zero (=a couple of lines of
code for each call; no I/O involved). Don't exaggerate this...it's not an
issue.
> 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.
Get current tx from TM and check with a tx->con hashmap. Not that hard/much
overhead.
> 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!
Again,
a) you're over exaggerating the overhead
b) once we get this done properly I think the solution will be clean and
simple. we just don't see the final solution, and hence reason from a
"design by exception" point of view.
IMHO of course.
> 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).
True.
As Marc pointed out, this is something that *should* be done (which all I am
arguing right now), but not necessarily have to be done *today*. So, from a
"I don't have time to do this and it's a lot of stuff to code" point of
view, I see your points perfectly. It's the "should we do this at all" point
that I don't agree with you with.
/Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
