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
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
