Hi!
> 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.
Well, we've covered it, but the conclusion of that (in my mind anyway) was
"yes, that's the way to do it, but not now".
> > > 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?
Because it should(?)
> > 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?
I see your point. The only way to get around this, of course, is to wrap the
connection. And this was not recommended, as pointed out by the spec
snippets you quoted.
Tricky one.
/Rickard
