[jboss-jira] [JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics
Nicky Mølholm (JIRA)
issues at jboss.org
Fri Oct 16 08:16:00 EDT 2015
[ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119050#comment-13119050 ]
Nicky Mølholm commented on WFLY-5537:
-------------------------------------
A workaround exists: annotate each method implementation (!) with @Lock ( READ )
( if you dont want implicitly auto upgraded WRITE locks ;) )
> Singleton EJBs with multiple views does not honor Lock semantics
> ----------------------------------------------------------------
>
> Key: WFLY-5537
> URL: https://issues.jboss.org/browse/WFLY-5537
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.CR2
> Environment: 10.0.0.CR2
> Reporter: Nicky Mølholm
> Labels: ejb, interceptor, singleton
>
> Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE).
> Here is an example:
> {code:java}
> @Singleton
> @Lock(LockType.READ)
> @Local({ GreeterSayMyName.class, GreeterSayHello.class })
> public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
> @EJB
> GreeterSayMyName myself;
> @Override
> public String sayHello() {
> return "hello from " + myself.sayMyName();
> }
> @Override
> public String sayMyName() {
> return "The Greeter";
> }
> }
> public interface GreeterSayHello {
>
> String sayHello();
>
> }
> public interface GreeterSayMyName {
> String sayMyName();
> }
> {code}
> Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:
> {noformat}
> 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
> {noformat}
> This happens completely randomly.
> The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist.
> When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock.
> ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list