On 29 Sep 00, at 10:24, Aaron Mulder wrote:
> Check out EJB 1.1 section 11.6:
>
> "This does not imply that the Container must interpose on every resource
> manager access performed by the enterprise bean. Typically, the Container
> interposes only the resource manager connection factory (e.g. a JDBC API
> data source) JNDI API lookup by registering the container-specific
> implementation of the resource manager connection factory object. The
> resource manager connection factory object allows the Container to obtain
> the XAResource interface as described in the JTA specification and pass it
> to the transaction manager. After the set up is done, the enterprise bean
> communicates with the resource manager without going through the
> Container."
>
> Using this as the guideline, I have checked in updates to Minerva
> that will allow you to keep a connection open during a commit or rollback
> (which is specifically allowed if you look at the examples in
> 11.3.3). However, it prints a warning message to stdout in this case, and
> if you keep the connection open it in *not* associated with future
> transactions, since the container only interposes at the time of the JNDI
> lookup, as suggested by the excerpt above.
Hi Aaron,
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.
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.
-Dan
I believe this behavior
> complies with the specification, even if it does not go as far as we might
> to permit undesirable code.
>
> Further, as a side note, recall that only session beans can use
> bean-managed transactions demarcation (11.3.1). It also appears that EJBs
> must use container-demarcated transactions in order to support
> client-demarcated transactions (the spec says the beans must be declared
> with the Required, Mandatory, or Supports transaction attribute [11.2.3]).
>
> Aaron
>
>
