Hi!
Aaron Mulder wrote:
> Well, if we just provide an XAConnection wrapper for JDBC 1.0
> connections, this could cause problems. You would keep the first
> connection locked, and when they requested a 2nd connection you'd give
> them a new one. All connections would be committed properly when you
> finished, but an individual connection in the middle would not have access
> to the the work done by an earlier connection (and indeed, this may cause
> a deadlock depending on your isolation level).
> So I guess this comes down to another requirement on the wrappers
> for 1.0 drivers - when you (in serial) check many connections out of the
> pool for the same transaction, you should always get the same underlying
> database connection, even if the XAConnection wrapper differs.
Correct. So, in effect some of the pooling is done in the wrapper
driver...
It would be sooo nice if everyone would be good fellows and implement
JDBC 2.0 drivers...
> However, I'm not sure how this would work if you check many
> connections out in parallel. For example, open one ResultSet to indentify
> interesting rows, and then execute an update using another connection for
> every row in the result set. Is this just not allowed? If it is allowed,
> and you close both connections and then come back later and request
> another, which should it be? Do we just say that you have to behave
> yourself if you know your drivers don't natively support JDBC 2.0?
I think you would get the same connection. We are talking about a tx
situation here, right? Because otherwise a check out of a con would
always be different results.
It's a tricky one, granted.
> In any case, the use of the connection will not be short-lived for
> JDBC 1.0 drivers in the case you describe, since the database conection is
> held open until commit time.
Good point. You're quite correct.
> But that raises an interesting question. What happens to
> transactions that are left open too long? Let's say your DBMS is locking
> rows or tables, and you open a connection and do some work and close it
> but never commit the transaction (in a stateful bean). Now you're prety
> likely to have DBMS problems... Do we just figure that's not our
> responsibility? Or do we attempt to close out dangling transactions after
> some period of time?
Tx's are supposed to have timeouts, which the Txmanager should check. I
know that the JOnAS Txman has a thread that GC's old tx's. We should
have one too.
Lots of thinking to do here, but we're on the right track methinks.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
