he, just as I was putting the fix, the "real" fix appeared quite easily :))) if there is no transaction, I can safely return to pool if there is a transaction, I let the sync return to the pool, do that code in ESI he! that was easy... I will fix it right now marc |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury |Sent: Tuesday, October 17, 2000 3:06 PM |To: jBoss Developer |Subject: [jBoss-Dev] Dead synchronization on remove: usage of Pools | | |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. |________________ | | |
