[JBoss JIRA] Created: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
5:35 p.m.
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, AS 5.0.0.CR1
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 @Remove
method is not executed either.
--
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
5:41 p.m.
New subject: [JBoss JIRA] Updated: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://jira.jboss.org/jira/browse/EJBTHREE-1500?page=com.atlassian.jira....
]
Galder Zamarreno updated EJBTHREE-1500:
---------------------------------------
Affects Version/s: 1.0.0-Beta3
(was: AS 5.0.0.CR1)
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 @Remove
method is not executed either.
--
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
10:05 a.m.
New subject: [JBoss JIRA] Updated: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://jira.jboss.org/jira/browse/EJBTHREE-1500?page=com.atlassian.jira....
]
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
10:56 a.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://jira.jboss.org/jira/browse/EJBTHREE-1500?page=com.atlassian.jira....
]
Carlo de Wolf commented on EJBTHREE-1500:
-----------------------------------------
Contradicts 4.4.3 bullet 3:
The following scenarios result in the PreDestroy lifecycle callback interceptor method(s)
not being called for an instance:
...
• A timeout of client inactivity while the instance is in the passive state. The timeout
is specified by the Deployer in an EJB container implementation-specific way.
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
11:17 a.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://jira.jboss.org/jira/browse/EJBTHREE-1500?page=com.atlassian.jira....
]
Galder Zamarreno commented on EJBTHREE-1500:
--------------------------------------------
Hmmm, let's clarify all this:
1.- When timed out bean from passivated state is removed, we currently do:
- a) invoke pre destroy method
- b) update removeCount
- c) remove context from cache map
2.- When timed out bean from ready state is removed, we currently do:
- a) remove context from cache map.
Now, taking in account your statement, we should be fixing this:
- 1a) needs to be removed as per 4.4.3.3
- We need to update removeCount for 2.
- Optionally: call pre destroy when bean removed in 2 as per 4.4
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
11:19 a.m.
New subject: [JBoss JIRA] (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://issues.jboss.org/browse/EJBTHREE-1500?page=com.atlassian.jira.plu...
]
Mirosław Michalski commented on EJBTHREE-1500:
----------------------------------------------
Problem stil exists in jboss-as 5.1 even with latest
jboss-ejb3-plugin-1.0.19-installer.jar (ejb3 v1.1.22) patch installed
Discrepancies between removing a bean in cache vs bean passivated
-----------------------------------------------------------------
Key: EJBTHREE-1500
URL: https://issues.jboss.org/browse/EJBTHREE-1500
Project: EJB 3.0
Issue Type: Sub-task
Affects Versions: AS 4.2.3.GA, 1.0.0-Beta3
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
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, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:06 p.m.
New subject: [JBoss JIRA] (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://issues.jboss.org/browse/EJBTHREE-1500?page=com.atlassian.jira.plu...
]
Galder Zamarreño reassigned EJBTHREE-1500:
------------------------------------------
Assignee: Carlo de Wolf (was: Galder Zamarreño)
Discrepancies between removing a bean in cache vs bean passivated
-----------------------------------------------------------------
Key: EJBTHREE-1500
URL: https://issues.jboss.org/browse/EJBTHREE-1500
Project: EJB 3.0
Issue Type: Sub-task
Affects Versions: AS 4.2.3.GA, 1.0.0-Beta3
Reporter: Galder Zamarreño
Assignee: Carlo de Wolf
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, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:58 p.m.
New subject: [JBoss JIRA] (EJBTHREE-1500) Discrepancies between removing a bean in cache vs bean passivated
[
https://issues.jboss.org/browse/EJBTHREE-1500?page=com.atlassian.jira.plu...
]
Carlo de Wolf reassigned EJBTHREE-1500:
---------------------------------------
Assignee: (was: Carlo de Wolf)
Discrepancies between removing a bean in cache vs bean passivated
-----------------------------------------------------------------
Key: EJBTHREE-1500
URL: https://issues.jboss.org/browse/EJBTHREE-1500
Project: EJB 3.0
Issue Type: Sub-task
Affects Versions: AS 4.2.3.GA, 1.0.0-Beta3
Reporter: Galder Zamarreño
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, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4633
days inactive
5945
days old
7 comments
4 participants
participants (4)
-
Carlo de Wolf (JIRA) -
Galder Zamarreno (JIRA)
-
Galder Zamarreño (JIRA)
-
Mirosław Michalski (JIRA)