14 Replies Latest reply: Sep 6, 2012 11:15 PM by tc7 RSS

Cache entry is not in use

prinzm Newbie

Hi!

 

We have a web application using the following technologies: JSF 2.0, EJB 3.1, JPA 2.0, JBoss AS 7.1 Final

 

Sometimes we get the following exception out of nowhere:

 

09:46:29,664 ERROR [org.jboss.ejb3.invocation] (http-10.99.0.10-10.99.0.10-8080-14) JBAS014134: EJB Invocation failed on component VehicleServiceBean for method public abstract java.util.List com.hji.common.service.VehicleService.findVehiclesBySearchCriteriaAndImporterIds(com.hji.common.domain.repository.VehicleRepository$VehicleSearchCriteria,java.lang.String,java.util.List,boolean): java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use

          at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:134) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:56) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:76) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:39) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:197)

 

(there is no 'caused by' statement)

 

Immediately afterwards the same error appears again as warning:

 

09:46:29,689 WARNUNG [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http-10.99.0.10-10.99.0.10-8080-14) #{vehicleInfoUiBean.searchVehicle}: java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use: javax.faces.FacesException: #{vehicleInfoUiBean.searchVehicle}: java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use

          at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]

          at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.10.Final.jar:]

          at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]

          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.10.Final.jar:]

          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.10.Final.jar:]

          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.10.Final.jar:]

          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.10.Final.jar:]

          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.10.Final.jar:]

          at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]

Caused by: javax.faces.el.EvaluationException: java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use

          at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:102) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          ... 25 more

Caused by: java.lang.IllegalStateException: JBAS014531: Cache entry {[36, -111, -104, -128, 61, -17, 73, 29, -101, 52, -7, -106, 46, -3, 44, -22]} is not in use

          at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:134) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.release(NonPassivatingBackingCacheImpl.java:56) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:76) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.release(AbstractCache.java:39) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:197) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:163) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:70) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:211) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:288) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:188) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ejb3.component.stateful.StatefulComponentIdInterceptor.processInvocation(StatefulComponentIdInterceptor.java:52) [jboss-as-ejb3-7.1.0.Final.jar:7.1.0.Final]

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

          at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72) [jboss-as-ee-7.1.0.Final.jar:7.1.0.Final]

          at com.hji.common.service.VehicleService$$$view22.findVehiclesBySearchCriteriaAndImporterIds(Unknown Source) [green-ejb.jar:]

          at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) [:1.6.0_23]

          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]

          at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]

          at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:111) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at com.hji.common.service.DomainService$Serializable$VehicleService$974932890$Proxy$_$$_Weld$Proxy$.findVehiclesBySearchCriteriaAndImporterIds(DomainService$Serializable$VehicleService$974932890$Proxy$_$$_Weld$Proxy$.java) [green-ejb.jar:]

          at com.hji.ui.compound.VehicleInfoUiBean.searchForVehiclesBySearchCriteria(VehicleInfoUiBean.java:536) [classes:]

          at com.hji.ui.compound.VehicleInfoUiBean.searchVehicle(VehicleInfoUiBean.java:313) [classes:]

          at sun.reflect.GeneratedMethodAccessor604.invoke(Unknown Source) [:1.6.0_23]

          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]

          at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]

          at org.apache.el.parser.AstValue.invoke(AstValue.java:262) [jbossweb-7.0.10.Final.jar:]

          at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:278) [jbossweb-7.0.10.Final.jar:]

          at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:39) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]

          at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

          at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

          ... 26 more

 

I have been searching the web for some time now but couldn't find any solution. Does anybody know this kind of error?

  • 1. Re: Cache entry is not in use
    Richard Hopkirk Newbie

    Hi there,

     

         I just recently had the same problem.  I tracked it down to passing an instance of a SFSB on class A (acquired via @Inject in class A)  to class B

    where we used this instance normally.  I suspect this is NOT allowed and class B should acquire it's own instance of the SFSB as the container

    may do some resource cleanup/passivation in the background such that the SFSB instance in class B is in an inconsistent state.  The fix was to not share SFSB instances between classes.  We actually refactored the SFSB into a CDI ManagedBean with an @Inject SLSB for transactional CRUD.

     

    Hope that helps,

    Rich

  • 2. Re: Cache entry is not in use
    prinzm Newbie

    Thank you for the hint, but unfortunately it does not help in our case since we do not pass on any injected SFSBs - all classes get their own injected instances.

    Nevertheless your approach with the CDI ManagedBean in combination with SLSBs looks promising, maybe I will try that...

  • 3. Re: Cache entry is not in use
    Stephen Coy Master

    Stateful session beans can timeout.

     

    Is there any chance that your sfsb instance has been expired by the container?

  • 4. Re: Cache entry is not in use
    prinzm Newbie

    How can I be sure that a SFSB instance has been expired?

  • 5. Re: Cache entry is not in use
    Richard Hopkirk Newbie

    You can use the @PreDestroy lifecycle event annotation on a method in the SFSB.

  • 6. Re: Cache entry is not in use
    prinzm Newbie

    Ok I added two methods annotated with @PreDestroy and @PrePassivate, but they are not called.

     

    I have now found a situation where I can reproduce the problem.

    The strange thing is, if I use the annotation @AccessTimeout in the class, then I get the IllegalStateException: Cache entry {[...]} is not in use

    But if I remove this annotation, then I get the following exception:

    ConcurrentAccessTimeoutException: JBAS014360: EJB 3.1 FR 4.3.14.1 concurrent access timeout on org.jboss.invocation.InterceptorContext@65a73e9c - could not obtain lock within 10000 MILLISECONDS

     

    I have no clue why this happens...

  • 7. Re: Cache entry is not in use
    Stephen Coy Master

    I was about to point you at javax.ejb.StatefulTimeout

     

    However, the above message suggests that you have multiple threads accessing your SFSB concurrently. You need to investigate why you're getting that timeout. Possibly a database deadlock or just a long running transaction? Beware of the "N+1 select" problem.

     

    As your SFSB has thrown that javax.ejb.ConcurrentAccessTimeoutException, your SFSB is now as dead as a dodo. The container considers a SFSB to be in an inconsistent state whenever it throws any kind of RuntimeException, so it discards it. Further attempts to access it will result in the IllegalAccessException.

  • 8. Re: Cache entry is not in use
    prinzm Newbie

    Ok I understand. Is it possible, that these concurrent requests are triggered via AJAX? I only ask, because we don't create any separate threads and AJAX calls are the only thing I could think of.

    And is there a way to prohibit multiple requests?

  • 9. Re: Cache entry is not in use
    Stephen Coy Master

    I reworded my response above as the spec changed with regard to concurrency in 3.1. 

  • 10. Re: Cache entry is not in use
    Stephen Coy Master

    Actually, it sounds a bit like the old "double click" problem. You have one or more users that just double clicks everything (I know that we do).

     

    Typically we block this at the UI by disabling controls with javascript following the submit event or whatever is appropriate.

  • 11. Re: Cache entry is not in use
    prinzm Newbie

    I have now found the source of the problem. We have several getters/setters in a managed bean, and some of these getters/setters use methods of an injected SFSB.

    So if we press the submit button, JSF accesses these getters/setters many times in a row and it seems, that this leads to concurrent calls to the SFSB.

     

    Just a simple example to explain what I mean:

     

    First it looked something like this:

     

    public String setName(String name) {

         user = this.employeeService.find(name);

    }

     

    Now it's like that:

     

    public String setName(String name) {

         if (user.getName().equals(name))

              return;

     

         user = this.employeeService.find(name);

    }

     

    The code was working perfectly fine in JBoss EAP 5, but since we switched to JBoss AS 7 (and Java EE 6) the problem occurred.

     

    If there is a better way to solve this issue or a kind of pattern, please let me know.

     

    Thanks

  • 12. Re: Cache entry is not in use
    Tony Herstell Master

    I have had this for ages and finally got rid of it.

     

    Found, in my case; I had a class called Identity (Session scoped as I wanted it to hang round as it's the logged in user)...

     

    @SessionScoped

    // Leverage EJB to get Transactional Support

    @Stateful

    // EL can find me...

    @Named

    public class Identity extends BaseController {

     

        private Logger logger = Logger.getLogger(Identity.class.getName());

     

        @Inject

        @UserUpdateEvent

        Event<User> updateEvent;

     

        // Access to the persistence store so we can read from the DB.

        @PersistenceContext

        private EntityManager em;

     

        private long loggedInUserId = UserContants.UNSET_ID;

        private String firstName;

        private String surName;

        private Set<ApplicationRole> roles;

     

    ...

    public User getLoggedInUser(long id) {

            User result = (User) this.em.createQuery("select u from user u where u.id=:id").setParameter("id", id).getSingleResult();

            if (result == null) {

                throw new RuntimeException("No User Found for ID:" + id);

            }

            return result;

        }

    ...

    }

     

     

    It contained a method:

        public void authenticateUser() throws Exception {

            User loggedInUser;

            if ((this.loginEmail != null) && (this.loginPassword != null)) {

                @SuppressWarnings("unchecked")

                List<User> results = this.em

                        .createQuery("select u from user u where u.email=:email and u.password=:password")

                        .setParameter("email", this.loginEmail).setParameter("password", this.loginPassword)

                        .getResultList();

                FacesContext fc = FacesContext.getCurrentInstance();

                // Add a Message to a specific field

                UIViewRoot viewRoot = fc.getViewRoot();

                UIForm uiForm = (UIForm) viewRoot.findComponent("loginStatusForm");

                FacesMessage msgField;

                if (results.isEmpty()) {

                    msgField = new FacesMessage("Login:", "Login Invalid");

                    msgField.setSeverity(FacesMessage.SEVERITY_ERROR);

                }

                else {

                    msgField = new FacesMessage("Login:", "Login Successful");

                    msgField.setSeverity(FacesMessage.SEVERITY_INFO);

                    loggedInUser = results.get(0);

                    loggedInUser.setLastLogin(new Date());

                    this.em.persist(loggedInUser);

                    this.loggedInUserId = loggedInUser.getId();

                    this.roles = loggedInUser.getApplicationRoles();

                    this.firstName = loggedInUser.getFirstName();

                    this.surName = loggedInUser.getLastName();

                }

                fc.addMessage(uiForm.getClientId(), msgField);

            }

        }

     

     

    I called this directly using el from a JSF page fragment:

     

    <p:commandButton id="authenticate_button" action="#{identity.authenticateUser}" value="#{messages.button_login}" update=":loginStatusArea :menuArea"/>

     

     

    Now; when I ripped out the routine and put it in a class called Authenticator:

    //Leverage EJB to get Transactional Support

    @Stateless

    // EL Can can find me...

    @Named

    public class Authenticator extends BaseController implements Serializable {

     

     

    and changed Identity to:

    @SessionScoped

    // EL can find me...

    @Named

    public class Identity implements Serializable {

     

        private Logger logger = Logger.getLogger(Authenticator.class.getName());

     

        @Inject

        Identity identity;

     

        // Access to the persistence store so we can read from the DB.

        @PersistenceContext

        private EntityManager em;

    ...

     

    and now call this from my page fragement:

     

    <p:commandButton id="authenticate_button" action="#{authenticator.authenticateUser}" value="#{messages.button_login}" update=":loginStatusArea :menuArea"/>

     

    The exception went away...

     

    Just trying to figure out WHY...

     

    I think its something to do with the Stateful bean hanging about in session scope for so long... and trying to keep a TXN open for too long....

     

    Can a welder perhaps explain...

     

     

    (Hope this helps find a simple explanation - and possibly a better message from weld runtime!)

  • 13. Re: Cache entry is not in use
    Patrick Garner Newbie

    I'm pretty sure I had a problem similar to y'all's, with the same java.lang.IllegalStateException: JBAS014531: Cache entry {[xxx]} is not in use.  My stack trace and resolution are located here:  Why when I convert managed bean to SFSB do I get TwoPhaseCoordinator.afterCompletion - returned failure for SynchronizationImple.

  • 14. Re: Cache entry is not in use
    tc7 Newbie

    Great discussion - this has helped us get to the bottom of this problem.

     

    The error we've seen is slightly different, but has the same effect, eg:

     

    Could not find SFSB MySessionEJB with {[-41, 127, 87, 65, 72, -126, 70, 4, -113, 11, 84, -7, -24, 53, 103, 68]}  Cause: Could not find SFSB MySessionEJB with {[-41, 127, 87, 65, 72, -126, 70, 4, -113, 11, 84, -7, -24, 53, 103, 68]}

    javax.ejb.NoSuchEJBException: Could not find SFSB MySessionEJB with {[-41, 127, 87, 65, 72, -126, 70, 4, -113, 11, 84, -7, -24, 53, 103, 68]}

            at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:62)

            at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

            at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:211)

            at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:363)

            at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:194)

            at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

            at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)

    ...

            at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)

            at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

            at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)

            at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)

            at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)

            at $Proxy21.getMyForView(Unknown Source)

            at com.myApp.asset.service.myappsession.MySessionDelegate.getMyForView(MySessionDelegate.java:939)

            at com.myApp.myappclient.web.MyDetailComponent$ViewDetailsAction.performImpl(MyDetailComponent.java:854)

            at com.myApp.struts.action.MyAppAction.performImpl(MyAppAction.java:241)

     

    cause

    We used to have synchronisation at the HTTP request processing level to prevent concurrent user requests. Recently we removed this protection (as it is restrictive for async requests).

    We found that this had no effect for Google Chome (as it seems not to allow concurrent requests of any kind), however for Firefox and IE this opened the door to some degree.

     

    We could reproduce the NoSuchEJBException in each of the ways described above:

     

    1) session bean timeout

    To test: reduce timeout to a small value using the following bean annotation:

    @StatefulTimeout(value=1,unit=TimeUnit.MINUTES)

    As an asside I have been unable to determine what the default timeout value is. The jdk documentation is useful - but I can only assume the default "-1" or disabled. Perhaps it's up to the container configuration.

    We might try using @SessionScoped instead - as that is what we're really after.

     

    2) double click

    We normally protect html links to prevent double-clicks. Once we relaxed our synchronisation rules this exposed a few areas where protection is missing. Where a 2nd thread enters a session bean method we also get the NoSuchEJBException error above.

     

    thanks.