I agree, clarification from jBoss on this will be great! > -----Original Message----- > From: Steve Magoun [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 15, 2001 11:57 AM > To: jBoss (E-mail) > Subject: RE: [jBoss-User] Re: Entities, Transactions & Commits (Oh > my...HELP!) > > > 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] > -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] List Help?: [EMAIL PROTECTED]
