[ http://jira.jboss.com/jira/browse/JBAS-3873?page=all ] Dimitris Andreadis closed JBAS-3873. ------------------------------------ Fix Version/s: (was: JBossAS-4.2.0.CR1) Resolution: Rejected Assignee: Dimitris Andreadis (was: Scott M Stark) Our interpretation of the standard is that in the "Supports" case, if a Xx is active the user code can mark it for rollback. If not an exception will be thrown. Same for getRollbackOnly(). 17.6.2.3 says that the "Supports" option with an active Tx should resemble the "Required" case. I think we should discuss this in the forums first. What was the motivation in the first place? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-3873?page=all ] Darran Lofthouse reopened JBAS-3873: ------------------------------------ In section 17.6.2.3 the spec also states : - The Supports transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the Supports transaction attribute. This clarifies that the bean implementation needs to be implemented to cope with both modes of execution. Then section 17.6.2.8 states: - The container must throw the java.lang.IllegalStateException if the EJBContext. setRollbackOnly method is invoked from a business method executing with the Supports, NotSupported, or Never transaction attribute. The third word of this sentence is 'must' so this is not optional. Actually 17.6.2.3 says "If the client calls with a transaction context, the container performs the same steps as described in the Required case." The steps for Required are described in section 17.6.2.2: - "The container must invoke an enterprise bean method whose transaction attribute is set to Required with a valid transaction context. If a client invokes the enterprise bean's method while the client is associated with a transaction context, the container invokes the enterprise bean's method in the client's transaction context. If the client invokes the enterprise bean's method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. The container automatically enlists all the resource managers accessed by the business method with the transaction. If the business method invokes other enterprise beans, the container passes the transaction context with the invocation. The container attempts to commit the transaction when the business method has completed. The container performs the commit protocol before the method result is sent to the client." At no point do these steps mention anything that conflicts with the statement in 17.6.2.3 - the steps that Supports must follow are just about transaction propagation, calling setRollbackOnly is handled in it's own section of the spec. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-3873?page=comments#action_12351752 ] Darran Lofthouse commented on JBAS-3873: ---------------------------------------- Yes which is why the spec states: - "The Supports transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the Supports transaction attribute." The spec does not provide any mechanism for the bean to identify if it can call setRollbackOnly so it has completely prohibited it. If a bean requires to do something transactional then it should not be using the transaction attribute of 'Supports', 'Supports' just lets an existing transaction pass through the bean without forcing a transaction to exist to call the bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-3873?page=comments#action_12351759 ] Darran Lofthouse commented on JBAS-3873: ---------------------------------------- The first link the generated Javadoc just states that the method will throw an IllegalStateException if the method is not allowed to be called, the spec then contains clarifications on when it can not be called. The second link just appears to be someone commenting on a Manning publication, his arguments do not seem to be based on anything specific. He is quoting that their publication says 'unspecified transaction context', this is correct - if you specify 'Supports' as the transaction attribute then the transaction context of the bean is unspecified - when the bean is called the transaction may or may not exist so technically it is not specified. If you say Required, RequiresNew or Mandatory you are guaranteed a transaction so the transaction context is specified. And the third post shows this problem has existed for a long time in JBoss, the basis of their discussion is some trial and error, their final solution is a workaround based on the current implementation. If the spec intended that a bean should be able to call setRollbackOnly for some scenarios when Supports has been specified there would have been a method available to see if there is a transaction - a CMT bean is not allowed to query the status of the transaction other than getRollbackOnly (Which also throws the same IllegalStateException). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-3873?page=all ] Dimitris Andreadis updated JBAS-3873: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) Moving issue to a next release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira