Resurrecting an old thread here....
I just read the EJB 1.1 spec, and it appears that jBoss is definitely
mishandling method calls when a method's trans-attribute is marked
'Supports' and no transaction context exists. Take a look at section 11.6.3
of the spec, "Handling of methods that run with 'an unspecified transaction
context'".
The EJB spec doesn't specify how the container is supposed to deal with
transactions here, but every example given says that the container should
access the resource manager:
"*The Container may execute the method and access the underlying resource
managers without a
transaction context.
*The Container may treat each call of an instance to a resource manager as a
single transaction (e.g. the Container may set the auto-commit option on a
JDBC API connection).
*The Container may merge multiple calls of an instance to a resource manager
into a single transaction.
*The Container may merge multiple calls of an instance to multiple resource
managers into a single transaction.
*If an instance invokes methods on other enterprise beans, and the invoked
methods are also designated to run with an unspecified transaction context,
the Container may merge the resource manager calls from the multiple
instances into a single transaction.
*Any combination of the above."
Am I way off-base in thinking that the intent of the spec was to let the
container decide how to persist data, with the assumption that the data *is*
persisted? Most of these examples suggest that the container build its own
transaction. Obviously the data is supposed to be persisted in these cases.
The first case ("The container may execute the method...without a
transaction context") seems to be what jBoss does. That's great, except IMHO
the intent of the spec is to make sure the data gets persisted while leaving
implementation up to the container developer; if a transaction isn't
supplied and isn't needed for persistence, the container shouldn't bother
with the overhead. If a tx *IS* needed for persistence, though, the spec
says (to me) that the container is responsible for creating one. jBoss
doesn't seem to do that, though. So we have an implementation that allows
persistence sometimes, but not always. Surely the specifiers did not want
non-deterministic behavior here? Or is there some reason such behavior is
desirable in an enterprise application? I spent quite a few hours trying to
figure out why jBoss refused to write my data to the DB even though other
application servers (Weblogic, Jonas, Enhydra, etc) had no trouble, and
after wading through mailing list archives I'm not the only person who's had
the same problem....
Steve
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
