Yet wrt WildFly, perhaps we could be friendly to these use cases, and a configuration
element to EJB subsystem, allowing to turn off the restriction…
On 25 Feb 2014, at 12:13, Eduardo Martins <emartins(a)redhat.com> wrote:
That’s wrt invoking EJBContext#getUserTransaction() only, but your
first quote section has an additional paragraph:
"The enterprise bean’s business methods, message listener methods, business method
interceptor meth- ods, lifecycle callback interceptor methods, or timeout callback methods
must not attempt to obtain or use the javax.transaction.UserTransaction interface.”
The rule is too restrictive in my opinion, there is no harm in obtaining the
UserTransaction I think, the restriction should be in using some of it’s methods, the same
way restrictions are applied to the methods of the java.sql.ConnectionIt’s listed in your
Anyway, the spec is what it is, I don’t think Seam should try to change it. If there is
enough utility in transaction control by Seam then it should clearly define how it
integrates with Java EE. If there isn’t, if it’s just a matter of getting some status from
transaction control, then alternatives should be used, such as the TSR. Well, Seam could
also give some “room” to the app, and use the TSR for any status retrieval, leaving the
usage of the Java EE UserTransaction for managing Seam's transaction, somehow IMHO
“fixing" the spec.
On 25 Feb 2014, at 02:44, Scott Marlow <smarlow(a)redhat.com> wrote:
> Hmm, looks like I was looking at the wrong EJB spec section. Should of been looking
> 18.104.22.168 Handling of getUserTransaction Method
> If an instance of an enterprise bean with container-managed transaction demarcation
attempts to invoke the getUserTransaction method of the EJBContext interface, the
container must throw the java.lang.IllegalStateException.
> The pull request https://github.com/wildfly/wildfly/pull/3213
has more context about
what happened (we used to throw the ISE pre-AS7, AS 7.0 didn't throw the ISE and we
are now throwing it again).
> org.jboss.seam.transaction.Transaction.getUserTransaction() shouldn't be used in
a CMT. I'm not sure of how to avoid that (perhaps some Seam configuration?)
> On 02/24/2014 08:55 PM, Jason T. Greene wrote:
>> Yes this is an application requirement. You can't use CMT and call commit!
>> Sent from my iPhone
>>> On Feb 24, 2014, at 2:27 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
>>> Is the below requirement for the application or the container?
>>> 8.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation
>>> This subsection describes the requirements for the Bean Provider of an
>>> enterprise bean using container-managed transaction demarcation.
>>> The enterprise bean’s business methods, message listener methods,
>>> business method interceptor methods, lifecycle callback interceptor
>>> methods, or timeout callback methods must not use any resource-manager
>>> specific transaction management methods that would interfere with the
>>> container’s demarcation of transaction boundaries. For example, the
>>> enterprise bean methods must not use the following methods of the
>>> java.sql.Connection interface: commit, setAutoCommit, and rollback; or
>>> the following methods of the javax.jms.Session interface: commit and
>>> IMO, I think that the requirement is on the application code and not the
>>>> On 02/24/2014 02:44 PM, Eduardo Martins wrote:
>>>> This may be interesting to discuss here, please have a look at
>>>> Other issues that are related and I’m aware
>>> I'm waiting to hear back from the Spring user but think that they will
>>> likely be able to solve it via existing Spring support for JTA. For the
>>> Spring case, the user might not of noticed the (using UT in CMT) problem
>>> if it was just a warning but we can't have it both ways.
>>>> wildfly-dev mailing list
>>> wildfly-dev mailing list
wildfly-dev mailing list