[jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated

[Galder Zamarreno (JIRA)]

     [ https://jira.jboss.org/jira/browse/EJBTHREE-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreno updated EJBTHREE-1500:
---------------------------------------

    Description: 
There's a discrepancy between removing a bean from the cache 
after a timeout when bean is in cache compared to when bean is 
passivated:

Example, when bean is in cache and has to be removed, this is called:

if (now - centry.lastUsed >= removalTimeout * 1000)
{
  synchronized (centry)
  {                                                                    
    it.remove();
  }
}

Now, when bean is passivated, this is called:

if (now - centry.lastUsed >= removalTimeout * 1000)
{
  get(centry.getId(), false);
  remove(centry.getId());
}   

And remove() method calls:

      if(log.isTraceEnabled())
      {
         log.trace("Removing context " + key);
      }
      StatefulBeanContext ctx = null;
      synchronized (cacheMap)
      {
         ctx = (StatefulBeanContext) cacheMap.get(key);
      }
      if(ctx == null)
         throw new NoSuchEJBException("Could not find Stateful bean: " + key);
      if (!ctx.isRemoved())
         container.destroy(ctx);
      
      ++removeCount;
      
      if (ctx.getCanRemoveFromCache())
      {
         synchronized (cacheMap)
         {
            cacheMap.remove(key);
         }
      }

What this means is that when a bean in cache is removed:

1.- removeCount is not updated

2.- container.destroy(ctx); is not executed and hence the @PreDestroy
method is not executed either. With regards to this, spec says:

Spec 4.4 "Note that a container can also invoke the PreDestroy method 
on the instance without a client call to remove the session object after 
the lifetime of the EJB object has expired."

  was:
There's a discrepancy between removing a bean from the cache 
after a timeout when bean is in cache compared to when bean is 
passivated:

Example, when bean is in cache and has to be removed, this is called:

if (now - centry.lastUsed >= removalTimeout * 1000)
{
  synchronized (centry)
  {                                                                    
    it.remove();
  }
}

Now, when bean is passivated, this is called:

if (now - centry.lastUsed >= removalTimeout * 1000)
{
  get(centry.getId(), false);
  remove(centry.getId());
}   

And remove() method calls:

      if(log.isTraceEnabled())
      {
         log.trace("Removing context " + key);
      }
      StatefulBeanContext ctx = null;
      synchronized (cacheMap)
      {
         ctx = (StatefulBeanContext) cacheMap.get(key);
      }
      if(ctx == null)
         throw new NoSuchEJBException("Could not find Stateful bean: " + key);
      if (!ctx.isRemoved())
         container.destroy(ctx);
      
      ++removeCount;
      
      if (ctx.getCanRemoveFromCache())
      {
         synchronized (cacheMap)
         {
            cacheMap.remove(key);
         }
      }

What this means is that when a bean in cache is removed:

1.- removeCount is not updated

2.- container.destroy(ctx); is not executed and hence the @Remove
method is not executed either.





> Discrepancies between removing a bean in cache vs bean passivated
> -----------------------------------------------------------------
>
>                 Key: EJBTHREE-1500
>                 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1500
>             Project: EJB 3.0
>          Issue Type: Sub-task
>    Affects Versions: AS 4.2.3.GA, 1.0.0-Beta3
>            Reporter: Galder Zamarreno
>            Assignee: Galder Zamarreno
>
> There's a discrepancy between removing a bean from the cache 
> after a timeout when bean is in cache compared to when bean is 
> passivated:
> Example, when bean is in cache and has to be removed, this is called:
> if (now - centry.lastUsed >= removalTimeout * 1000)
> {
>   synchronized (centry)
>   {                                                                    
>     it.remove();
>   }
> }
> Now, when bean is passivated, this is called:
> if (now - centry.lastUsed >= removalTimeout * 1000)
> {
>   get(centry.getId(), false);
>   remove(centry.getId());
> }   
> And remove() method calls:
>       if(log.isTraceEnabled())
>       {
>          log.trace("Removing context " + key);
>       }
>       StatefulBeanContext ctx = null;
>       synchronized (cacheMap)
>       {
>          ctx = (StatefulBeanContext) cacheMap.get(key);
>       }
>       if(ctx == null)
>          throw new NoSuchEJBException("Could not find Stateful bean: " + key);
>       if (!ctx.isRemoved())
>          container.destroy(ctx);
>       
>       ++removeCount;
>       
>       if (ctx.getCanRemoveFromCache())
>       {
>          synchronized (cacheMap)
>          {
>             cacheMap.remove(key);
>          }
>       }
> What this means is that when a bean in cache is removed:
> 1.- removeCount is not updated
> 2.- container.destroy(ctx); is not executed and hence the @PreDestroy
> method is not executed either. With regards to this, spec says:
> Spec 4.4 "Note that a container can also invoke the PreDestroy method 
> on the instance without a client call to remove the session object after 
> the lifetime of the EJB object has expired."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira