I just patch 2.4.5 to work the same as 3.0. In 3.0, I don't obtain a bean lock reference on a cache insert and don't remove the reference on a cache release. It really isn't worth saving the extra memory allocation. See if Branch_2_4 solves this problem. Could you?
Thanks, Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Christian Riege > Sent: Thursday, February 21, 2002 4:10 PM > To: Bill Burke > Cc: JBoss Dev list > Subject: RE: [JBoss-dev] Bug?: no rollback on tx timeout > > > hi, > > On Thu, 2002-02-21 at 21:56, Bill Burke wrote: > > I thought a bean wasn't allowed to be passivated if it was > involved with a > > transaction? > > > > Check out the canPassivate method on the instance cache. > > you're correct. the thrown exception is not a NPE but instead an > IllegalStateExeption; we talked about this in private mail on Jan 17, > check your archives if you still have them ... Anyways, I will re-post > my mail below; I didn't have any time to look further into this issue. > All line numbers mentioned refer to CVS Branch_2_4; but I *think* the > bug is still in RH: > > --< snip >-- > > On Thu, 2002-01-17 at 17:30, Bill Burke wrote: > > Dude. Your fix was a good one. Just add > > getContainer().getLockManager().removeLockRef(id); in > > AbstractInstanceCache.release()? Or is there something more? > > Actually I don't know ... what happens in the PassivationJob() that is > scheduled via schedulePassivation(ctx) in the > AbstractInstanceCache.release() ?! > > From the looks of it, PassivationJob.execute() inserts the bean into the > cache again, if it can't be passivated -- shouldn't we actually keep the > lock on it in this case (lines 705ff)? I'm a bit puzzled ... > > The fix also produces IllegalStateExceptions in QueuedPessimisticEJBLock > (line 441) when the passivation kicks in and a transaction is still > running ... we've seen this b/c we are running with ridiculously low > settings for the cache for debugging this. > > Actually I *think* that the call to removeLockRef() should happen at the > end of the PassivationJob -- although that also doesn't seem right ... > we should possibly check if there's a transaction running on the bean > before trying to passivate it. > > Do you get my leanings? :) > > --< /snip >-- > > to reproduce, set your cache settings ridiculously low (i.e. 100ms max > lifetime or something like that) and run one of the EB test cases vs. > the server. > > I'm sorry if the explanation of the issue at stake is a bit vague but I > don't have sufficient insights into what is happening and why; under > "normal" circumstances this bug won't bite you but it will happen when > your cache is running low and/or your transaction is taking a lot of > time (e.g. longer than the max cache lifetime) > > best regards, > christian > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
