Ok, here is a deep one (code)... So we run a thread that removes a bean, the stack of interceptors for a CMT bean is TxIntCMT (TIC) -> EntityInstanceInterceptor (EII) -> EntitySynchronizationInterceptor (ESI) so when the thread comes back it reaches EII and since the operation was remove() the id is null (set in the container interceptor). Now that bean is going to the pool, even though it is still associated with a tx (the Tx associated with the remove() operation). Another bean comes in and requests a different id, gets assigned that ctx (even though it is still associated with a tx) and we never really test the tx association on a new candidate since it is cleaned when we go back to the pool. Now, the first thread reaches TIC and commits the tx of remove() and the ESI gets called on the synchronization and it calls the ctx, now assigned to an entirely different instance to "commit" gaddamit "commit!!!", and the poor context has no idea as to what is going on... dangerous. Also the fact that we only notifyAll on getId!= null is potentially dangerous as well we need to notify. Ok the simplest way to fix this problem above is to remove the usage of pools for now... yes I can hear the guys going "what?". Doing it cleanly takes time and we don't have time... basically we would need to check for a transaction association upon reentrancy in the pool (which is always going to be the case since most remove() operation will be transactional) and hold the instance until the transaction commits... hugh... by commenting the return to pool in the EIS I fix the problem for sure. As a final point I will say that the passivating caches are more important to me than working on the heap... we were succesful with tons of beans and threads and a heap at 6M, let's see if that is kinda stable. We have been told over and over that real "server VM" don't need no pools, let's see if this is real. marc ________________ Marc Fleury, PhD CTO, Telkel Inc. ________________
