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, > beware....I'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
