On Tue, 23 May 2000, Rickard [iso-8859-1] �berg wrote:
> You're not paying attention ;-) The work is tied to the tx not the
> connection. So the use of the *connection* will always be short-lived.
> I.e.
> * start tx
> * use con
> .. time passes
> * use con
> .. time passes
> * use con
> * commit tx
>
> So even though the tx itself is taking a really long time, the use of
> the connections is short, hence no need for timestamping on every
> action. Just getConnection.
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.
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?
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.
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?
Aaron
