> Sure: Not sure it's going to get you much. Why go out of our way
> to support bad coding practices? I'd rather just let you code poorly, and
> print a warning message every time a connection is held across the
> boundary of a transaction.
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.
> The big problem is re-attaching a connection to a new
> transaction. When you create a new transaction (via UserTransaction or
> calling into a bean with a Connection in the instance variable), how
> should the server determine which Connection(s) to include in that
> transaction? You can't just override the methods of Connection to check,
> since someone could very well hold a PreparedStatement or ResultSet in an
> instance variable, and with updateable result sets this gets ugly.
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.
> Actually, now that I think about it, I'd rather just make the
> server throw a more coherent exception like "SQLException: You have
> attempted to close a transaction with outstanding connections". I dunno -
> this is pretty ugly. As I said, in the end, you'd have to override
> practically every method in JDBC
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.
> to check the current Transaction if you
> really want to be able to leave JDBC objects hanging out between
> transactions or start a transaction with existing objects and expect them
> to be added to your transactions. This is 1000kg of work for us due to 5g
> bad coding on the part of the bean developer.
You are waaaaay overestimating that work.
> We'd definitely want to go the Proxy route to make this work,
Either that or a simple refactoring of that code (such as
validateConnection() above). Either would work.
> but
> now we're sacrificing performance and effort to support bad coding.
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.
> Plus, Minerva has to have different versions for 1.2 and 1.3, and we're
> jBoss specific, and, and, and... Sigh.
Nope, if we go the proxy route then we use the 1.2 proxies (just as I did in
the DataSourceImpl).
I think you are overwhelming yourself by the task unnecessarily. If you
don't want to do it yourself, that is one thing which is cool, but don't
turn down the whole idea based on that.
regards,
Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
