[
https://issues.jboss.org/browse/WFLY-4834?page=com.atlassian.jira.plugin....
]
Carlo de Wolf resolved WFLY-4834.
---------------------------------
Assignee: Carlo de Wolf
Resolution: Rejected
This needs to be specified out better.
{{ConcurrentAccessTimeoutException}} is a subclass of {{EJBException}} so it works as
specified.
What you really want is an immediate exception whenever the outlined scenario occurs.
I'm not sure however whether that is easily detectable.
Throw EJBException instead of ConcurrentAccessTimeoutException when
access attempt of a Session EJB already in a tx by another tx
---------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-4834
URL:
https://issues.jboss.org/browse/WFLY-4834
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.0.0.Alpha3
Reporter: Brad Maxwell
Assignee: Carlo de Wolf
Attachments: WFLY-4834.jar
EJB3.1 specification chapter *4.6.4 Restrictions for transactions*
- A session bean instance can participate in at most a single
transaction at a time.
- If a session bean instance is participating in a transaction, it is an
error for a client to invoke a method on the session object such that
the transaction attribute specified in the bean’s metadata annotations
and/or the deployment descriptor would cause the container to execute
the method in a different transaction context or in an unspecified
transaction context. In such a case, the javax.ejb.EJBException will be
thrown to a client of the bean’s business interface/
With this flow:
- SLSB start with @REQUIRED
- SLSB request a reference to a SFSB
- call a method SFSB.x() @REQUIRED
- call another method SFSB.y() @REQUIRES_NEW
It fails with:
javax.ejb.ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR
4.3.14.1 concurrent access timeout on
org.jboss.invocation.InterceptorContext@4375b1 - could not obtain lock
within 5000 MILLISECONDS|
It should throw an EJBException as the Session Bean is already participating in a
transaction instead of ConcurrentAccessTimeoutException
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)