On 29 Sep 00, at 11:27, Aaron Mulder wrote:
> On Fri, 29 Sep 2000, Dan OConnor wrote:
> > What would it mean for a bean method to execute in a transaction
> > if the resources it used weren't transactional? Nothing. That's why
> > 11.3.1.1 says that if non-transactional resources are used, the
> > bean's methods should use the NotSupported transactional
> > attribute.
>
> I read 11.3.1.1 to be discussing resources that cannot be
> controlled by the transaction manager, not resource that can be but
> currently aren't. Probably splitting hairs. I agree that this resulting
> situation is not something a bean developer wants. I think this means the
> bean developer should avoid it.
>
> > The specification is silent on the implications of saving a
> > transactional resource such as a connection between business
> > method calls. If it were legal for the container to make those
> > resources non-transactional, this would certainly have been
> > mentioned (EJB components using this pattern in transactional
> > methods would not be portable). To me this implies that you must
> > be able to re-enlist an existing, open connection into a new
> > transaction.
>
> Well gosh, if you are supposed to be able to re-enlist and
> existing open connection, how do you do it? The logical place for such a
Hi Aaron,
If a bean "checks out" a connection from the pool, and doesn't put
it back (i.e. doesn't call close), you know that it still has it when
the next business method is called. Would it work to just go
ahead and enlist it in any new transaction? (There can't be more
than one transaction for that bean going at once...)
Tracking a list of checked-out resources would also make cleanup
easier after a system exception, if we don't do this already. Just a
thought...
-Dan
> 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. 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 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!
> Since this behavior could be implemented by the container vendor
> or DBMS vendor, and there are dozens of each, and the specification *never
> indicates* what the proper behavior would be, I have to think that any
> code that uses this construct is not going to be portable no matter what
> we do.
> Someone should probably suggest that the EJB 2.0 group address
> this.
>
> Aaron
>
>
