> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Wednesday, July 04, 2001 9:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] comments on new instance interceptors and > locking > [snip > |- I really think that doing a wait() rather than a wait(5000) is a really > |really bad idea. If a transaction timeout happens, I don't > think a thread > |that is in a ctx.wait() or a ctx.getTxLock().wait() will ever wakeup and > |actually do a rollback and release all it's locked entities and > resources. > > hmmm analyse that again. If someone is waiting and the transaction > times-out (the one waiting) the upon waking up you see that in > the loop. If > the transaction in the component times out, well actually that is > one of the > bugs I fixed, then you do get notified with a txLock.notifyAll(). > > what case can go wrong? > I'll do this on Monday, but if somebody feels the itch, try out the classic deadlock scenario and see if it actually times out and rollsback the transaction. Trans 1: Trans 2: get A get B sleep sleep get B get A I'm very suspicious that it won't rollback and release with the wait() code in there. > |I am VERY unfamiliar with the TM code, but take a look at > |TxCapsule.timedOut(). This method only marks the transaction as ROLLING > |back and does nothing else. I can find no where in the jboss > |codebase where > |Thread.interrupt() is called in relation to transaction timeouts. > |(I'd test > |out this theory myself, but I'm on "vacation" and won't really be able to > |until Monday.) > > I am not following you, expand when you come back. A transaction time out > doesn't interupt the thread I don't even think we need to, it wakes up and > tests for timeout. > When the transaction times out, who will wakeup threads in EntityInstanceInterceptor doing a wait()? Again, when a timeout happens, I think the TM only marks the transaction as STATUS_ROLLBACK, and doesn't do any interrupting or do a loop through the transaction's InstanceSynchronizations. I'll try out the classic deadlock scenario on Monday. > |I guess there is 2 solutions here. One, have transaction timeouts > |interrupt > |their threads, or Two, have a wait(5000) block in > EntityInstanceInterceptor > |as well as: > > re: taste wait(5000) or wait(), I actually found the above bug by turning > the wait() :) > > take your previous catch, you got it by looking at the code, if > not then we > would have gotten it immediately because someone would have said "lock, > freeze". I would rather hear about it early on than not, when it is > stabilized and we go with a production version I have no problem about > putting wait(5000); > Oh, ok, so wait() is in there for debugging purposes. > |Well, I hope I'm making sense here. It's the 4th and I have a > |belly full of > |beer and BBQ. > Burp! > hey thanks, I feel I am in a fighter plane and I am working on oxygen > supply, not much to breeze in that code so I am always happy to > see a fellow > bomber plane fly by, feel less alone. > > Actually good work very useful and I am impressed and there is > much more we > can do. > My motivations are purely selfish. This stuff is fun!(Yes, I'm a dork...). Now, I'm really off until Monday, Bill _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
