RE: [JBoss-dev] Bug?: no rollback on tx timeout

[Bill B. <bi...@bu...>]

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: jbo...@li...
> [mailto:jbo...@li...]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
> Jbo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development