Right, but does this not mean we are leaking cache entries in this scenario? This did not appear to be a recursive call so why are there more than one lock ref here?
Adrian Brock wrote:
That is because the instance synchronization still holds the lock reference. The cache also takes a lock reference at passivation.
1+1 == 2 > 1 which is what tryToPassivate checks.
In plain English, the Cache is saying I cannot passivate this instance because somebody else besides me has a lock reference.
The fact that "the somebody else" has told the Cache to remove it is not taken into account.
Regards, Adrian
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
