> 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.
> 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.
> The only way for the container to manage this is
> to:
>
> 1) track every single JDBC resource and the object that originally
> created it so that subsequent transaction initiation where the initiator
> is the same object will re-enlist the resource (incomplete [imagine child
> beans in the same transaction] and impossible to boot)
>
> 2) interpose on every JDBC method to check the current transaction
> context, which the spec specifically suggests you don't do.
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 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
