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


Reply via email to