[jboss-user] [JBossCache] - Re: Problems with NodeLocking algorithm

[jacek187]

Hi
I found next problem with node locking and transaction timeouts.
On WebLogic (and on another application servers too) if transaction is timed-out and thread witch timed-out transaction is still working on request (i.e. is waiting on locks, reading file etc., important is that transactional method invocation has not ended before timeout) server is calling rollback on timed-out transaction in another, separate thread.

This give a chance to release used resources - db connections, locks etc.

Problem is, that sometimes treecache dosen't release acquired WL when timed-out transaction is rolledback in separate thread.

I have reported some moths ago similar bug http://jira.jboss.com/jira/browse/JBCACHE-923, now effects are identical, but scenario is more complicated.

Scenario4:
Cache has node /a.
new transaction is started. Transactional method is doing something on cache (i.e. /b node is created) (transaction is registered in InvocationContext) and waits until transaction has timed-out. Transaction has timed out (i smarked by container as rollBackOnly). Now method will modify /a node (until now no WL was acquired on this node). Warning about (not ACTIVE or PREPARING) current transaction status from getCurrentTransaction is printed, and null is passed as GlobalTransaction argument, but  in InvocationContext is still transaction stored, so pessimistickLockIntercepotr still can use this transaction object. 
This Thread has just acquired WL on node /a and now is trying to record this lock. Assume that thread sleeps now in recordNodeLock (simulate heavy-load), gtx is not null. Now container has decide to rollback this transaction. Rollback phase is executed. Most important from this operation is, that TransactionEntry from transactionTable is removed. Rollback phase is finished, Thread-0 can continue execution. Thread-0 is executing:
         cache.getTransactionTable().addLock(gtx, lock);
but corresponding transactionEntry couldn't be found, because it was removed in rollback phase. Unfortunally only error is logged, and code execution is continued. Information about acquired WL is never used, and this lock never will be released.

This issue was observed in real application. 
I think, that 
* additional condition must be added - if acquiredLock can;t be recorded, he must be immediatly released and exception should be thrown.
* what is thew sense of continue cache opertions when transaction is marked as rollbackOnly? maybe immediatly exception should be thrown? (something like container)

Jacek Halat

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4083227#4083227

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4083227