[JBoss-dev] Bug?: no rollback on tx timeout
All, I've voiced this concern in the past. When a transaction times out, why does the method TxCapsule.timedOut only set the status of the transaction as STATUS_MARKED_ROLLBACK? Why doesn't it actually do a rollback? A very serious side effect is this scenario: Something hangs indefinately within a transaction. With Entity pessimistic locking all locks are held onto and the bean is locked forever until you kill the server. I can fix this. 1. in TxCapsule.timedOut call rollback() 2. in TxInterceptors don't base tx status checks on STATUS_MARKED_ROLLBACK Side effects of the fix are as follows: 1. What if a transaction is not hanging but takes long than the timeout? How do we make sure that a JDBC connection is not returned to the pool while the sluggish timedout thread could be making JDBC calls? On a rollback, can we discard the connection totally? Or maybe this is already happening. I need input. Thanks in advance, Bill P.S. I need to solve this problem for work. So if I get no feedback, bewareI'll be making changes. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug?: no rollback on tx timeout
hi, On Thu, 2002-02-21 at 20:47, Bill Burke wrote: > P.S. I need to solve this problem for work. So if I get no feedback, > bewareI'll be making changes. There's one more issue which might be related to this (or not at all, I don't have the necessary insights): When a Bean is enrolled in a transaction and the bean gets passivated (either because the transaction is taking too long or your bean cache is running low), the server will throw a lot of NPE's and the transaction will be marked for rollback -- even if the DB stuff would actually commit at the end of the transaction. Regards, Christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bug?: no rollback on tx timeout
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. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Christian Riege > Sent: Thursday, February 21, 2002 3:26 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 20:47, Bill Burke wrote: > > P.S. I need to solve this problem for work. So if I get no feedback, > > bewareI'll be making changes. > > There's one more issue which might be related to this (or not at all, I > don't have the necessary insights): > > When a Bean is enrolled in a transaction and the bean gets passivated > (either because the transaction is taking too long or your bean cache is > running low), the server will throw a lot of NPE's and the transaction > will be marked for rollback -- even if the DB stuff would actually > commit at the end of the transaction. > > 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
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
RE: [JBoss-dev] Bug?: no rollback on tx timeout
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
Re: [JBoss-dev] Bug?: no rollback on tx timeout
OK, now I'm confused. Looking at (some of) the code I would think that: 1. If nothing is hanging, just taking a really long time, when it all gets done the tx will be rolled back just fine, and all resources released. 2. If the db call is hanging, the tx will be marked for rollback, but since the db call is waiting and waiting, nothing will ever be released. I would expect that calling rollback on the tx would have essentially no effect, since the "active" thread is waiting for IO. I'm no threading expert, but I can't find any way of communicating with the hung thread to force it to return. I guess you might be able to: Mark all the objects (mostly enterprise contexts) in the tx as invalid tell some interceptors to stop as soon as possible, in case the db call eventually returns throw out or release the lock objects the tx/method call have, so other calls can get new locks on new copies of the objects. call destroy asynchronously on the managed connections that are hanging. This might or might not have an effect of making the connection throw an exception: it depends on the driver. Calling rollback on a hung connection is apt to result in the thread doing the calling hanging also. Figuring out which connections are associated with which objects and transactions is not being kept track of at the moment. (the tx manager keeps track of XAResources in a tx, but local transactions don't use XAResources and there is no way to ge back from XAResource to ManagedConnection). The new ConnectionManager I am working on does keep track of thread/object/connection association, so this might be possible to extend to destroying ManagedConnections for a thread/tx/object on request. How does this relate, if at all, to what you are thinking of? thanks david jencks On 2002.02.21 14:47:57 -0500 Bill Burke wrote: > All, > > I've voiced this concern in the past. When a transaction times out, why > does the method TxCapsule.timedOut only set the status of the transaction > as > STATUS_MARKED_ROLLBACK? Why doesn't it actually do a rollback? > > A very serious side effect is this scenario: > > Something hangs indefinately within a transaction. With Entity > pessimistic > locking all locks are held onto and the bean is locked forever until you > kill the server. > > I can fix this. > > 1. in TxCapsule.timedOut call rollback() > 2. in TxInterceptors don't base tx status checks on > STATUS_MARKED_ROLLBACK > > > Side effects of the fix are as follows: > > 1. What if a transaction is not hanging but takes long than the timeout? > How do we make sure that a JDBC connection is not returned to the pool > while > the sluggish timedout thread could be making JDBC calls? On a rollback, > can > we discard the connection totally? Or maybe this is already happening. > > I need input. > > Thanks in advance, > > Bill > > P.S. I need to solve this problem for work. So if I get no feedback, > bewareI'll be making changes. > > > ___ > 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
Re: [JBoss-dev] Bug?: no rollback on tx timeout
> I'm no threading expert, but I can't find any way of communicating with > the hung thread to force it to return. thread.interrupt() works in most cases. It causes the thread to throw an InterruptedException. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bug?: no rollback on tx timeout
Hey, thanks for replyingComments are in-lined. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 21, 2002 5:25 PM > To: Bill Burke > Cc: Jboss-Dev > Subject: Re: [JBoss-dev] Bug?: no rollback on tx timeout > > > OK, now I'm confused. Looking at (some of) the code I would think that: > > 1. If nothing is hanging, just taking a really long time, when it all gets > done the tx will be rolled back just fine, and all resources released. > Yeah, that's not the problem though > 2. If the db call is hanging, the tx will be marked for rollback, > but since > the db call is waiting and waiting, nothing will ever be > released. I would > expect that calling rollback on the tx would have essentially no effect, > since the "active" thread is waiting for IO. I'm no threading expert, but > I can't find any way of communicating with the hung thread to force it to > return. > You have a point. Calling rollback from a different thread would just hang the TimeOut thread as well. Is that what you're saying? I'm pretty sure that in JDK 1.3.x, there is no way of interrupting a thread waiting for IO. I've tried it before without success. Can somebody back me up on that statement? H so the real solution is release the EntityBean locks. How can I do this generically though? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bug?: no rollback on tx timeout
I don't think that works. All it does I think is set a boolean flag internally. > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 21, 2002 5:37 PM > To: David Jencks > Cc: Bill Burke; Jboss-Dev > Subject: Re: [JBoss-dev] Bug?: no rollback on tx timeout > > > > I'm no threading expert, but I can't find any way of communicating with > > > the hung thread to force it to return. > > > thread.interrupt() works in most cases. It causes the thread to throw > an InterruptedException. > > -dain > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Bug?: no rollback on tx timeout
On 2002.02.21 17:36:46 -0500 Dain Sundstrom wrote: > > I'm no threading expert, but I can't find any way of communicating with > > > > the hung thread to force it to return. > > > thread.interrupt() works in most cases. It causes the thread to throw > an InterruptedException. I think this is only if the thread is wait()ing or sleep()ing. If it is waiting for IO (like a db response) it's not guaranteed or likely to do anything-- at least this is what "The Java Programming Language, 3rd ed." says pretty explicitly. david jencks > > -dain > > > > ___ > 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
Re: [JBoss-dev] Bug?: no rollback on tx timeout
On 2002.02.21 17:38:35 -0500 Bill Burke wrote: > Hey, thanks for replyingComments are in-lined. likewise > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 21, 2002 5:25 PM > > To: Bill Burke > > Cc: Jboss-Dev > > Subject: Re: [JBoss-dev] Bug?: no rollback on tx timeout > > > > > > OK, now I'm confused. Looking at (some of) the code I would think > that: > > > > 1. If nothing is hanging, just taking a really long time, when it all > gets > > done the tx will be rolled back just fine, and all resources released. > > > > Yeah, that's not the problem though I figured as much... > > > 2. If the db call is hanging, the tx will be marked for rollback, > > but since > > the db call is waiting and waiting, nothing will ever be > > released. I would > > expect that calling rollback on the tx would have essentially no > effect, > > since the "active" thread is waiting for IO. I'm no threading expert, > but > > I can't find any way of communicating with the hung thread to force it > to > > return. > > > > You have a point. Calling rollback from a different thread would just > hang > the TimeOut thread as well. Is that what you're saying? > > I'm pretty sure that in JDK 1.3.x, there is no way of interrupting a > thread > waiting for IO. I've tried it before without success. Can somebody back > me > up on that statement? "The Java Programming Language, 3rd ed." says that pretty explicitly, so I think even if you found a way that worked sometimes it would be almost certain to not work other times. > > H so the real solution is release the EntityBean locks. How can I do > this generically though? Hmmm also, maybe we have to put all the entities back into the GlobalTxEntityMap with a flag saying if they are dirty so it can be used both for the read-only and for killing all the locks in this tx timeout case. Or maybe we need 2 maps here...??? david jencks > > Bill > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Bug?: no rollback on tx timeout
|case. Or maybe we need 2 maps here...??? David, KISS marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
