On Wed, 27 Sep 2000, Rickard Oberg wrote:
> No. This is a limitation of the current DataSource implementation. The
> problem is that when you do getConnection() you get a wrapper connection
> that actually holds a real connection under the hood. Since the XA hooks are
> in Connection.close() it is not possible to get a connection wrapper and
> reuse it a lot of times.
>
> IMHO the connection wrapper should be recoded so that a connection is
> retrieved for each Connection call ( vaguely remember this being discussed
> some while back). This will
> a) allow Connections to be gotten in setInitialContext() and reused many
> times
> b) make it impossible for beans to "steal" connections and not hand them
> back
>
> Aaron, any comments on this?
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.
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.
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 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.
We'd definitely want to go the Proxy route to make this work, but
now we're sacrificing performance and effort to support bad coding.
Plus, Minerva has to have different versions for 1.2 and 1.3, and we're
jBoss specific, and, and, and... Sigh.
Aaron
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
