On Fri, 29 Sep 2000, Rickard Oberg wrote:
> > Well gosh, if you are supposed to be able to re-enlist and
> > existing open connection, how do you do it?
>
> For each Connection call you simply do
> a) tx running -> check tx->con map, if not found then get new one from pool
> and execute
> b) no tx running -> get from pool and execute
>
> Just as I argued before.
Rickard, this does not re-enlist a prior connection with a new
transaction. What you describe is exactly the process for getting a new
connection, not reusing an existing one. Unless, of course, we move to
the model where the whole JDBC implementation is just a facade and there
is no underlying "Real" connection unless a JDBC call or child object is
active. Which I think we've covered before.
> > The logical place for such a
> > method would be in UserTransaction, but there's nothing there. So it's
> > left for the Container to handle. But the section I quoted specifically
> > stated that the container need not interpose *except* during the original
> > JNDI lookup.
>
> Hm.. isn't this for pure XA drivers only? I think that in the case of our
> JDBC 1.0 wrapper we need to do this ourselves, i.e. put more control over tx
> mgmt in the actual wrapper.
Hmmm... Perhaps. But why do you assume that a vendor's "pure
XA" implementation would behave like this?
> I don't agree with 2. This is only the case IMHO when a real XA driver is
> used (in which case you only need to register the Connection once, and that
> registration can the be reused infinitely). In the case of the wrapper
> driver (which I assume is what we are talking about) then we need the "check
> on each call". Again, as argued earlier by self.
I don't believe that the real XA registration can be used
indefinitely. Let's say I use the Oracle XADataSourceImpl. I get an
XAConnection, get it's XAResource, register the XAResource with the
current transaction, then finally get a Connection from the
XAConnection. Now I do stuff, complete the transaction, but keep the
Oracle Connection open.
Now another call comes on, for which there is of course a new
transaction. The container is never told that the bean is using a DB
resource, so it does nothing. The bean reuses it's old
Connection. As far as the Oracle connection knows, it has no transaction
- or worse yet, all the work is done on behalf of the transaction you
originally registered with the Oracle XAResource.
See, how could the Oracle Connection know to register with the
current transaction? You don't give the Oracle XADataSource or
XAResource or XAConnection or Connection a reference to the
TransactionManager, and there's no standard location for the
TransactionManager in JNDI. There's no way for the Oracle connection to
know its transaction is invalid, or what the new transaction should be.
So I conclude that the feature you are requesting would
specifically not be supported by a DB vendor implementing a JDBC 2
Optional Package driver. Do you disagree?
Aaron
> > I agree that this whole discussion is due to the fact that the
> > spec does not mention keeping connections around. But I think all the
> > hooks for container action are in the XAResource, and between that and the
> > section I quoted, I think you're reading too much into the silence of the
> > spec. Further, consider again that this is not even in our hands if the
> > DBMS vendor implements the spec properly!
>
> Correct.
>
> /Rickard
>
>
>
