DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32250>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32250 Summary: DB2 deadlock running with client side transactions enabled Product: Slide Version: 2.1 Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P2 Component: Transaction Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I found that when I tried to use the client tx support that the server would deadlock in the db2 store client during the transaction commit phase because the AbstractWebdavMethod.run() method was performing some operations that needed access to the db2 store but the commit operation (a special variation of the UnlockMethod) was running outside of any transaction since it was, obviously, committing a transaction and no longer "enlisting" operations for that transaction. So after much investigation and experimentation I came to realize that the operations causing the deadlock, a check for the existence of the target for the unlock and a lock cleanup routine should probably not be running during a commit since all we really want to do in the commit is commit what we've already done and perform the special unlock that opens our stores to new transactions. So to fix the problem I've made the existence check and lock cleanup code in AbstractWebdavMethod.run() conditional upon the current request not being an UnlockMethod that is peforming the commit or abort command. In all other cases this code will be executed. Then I needed to ensure that every method called from the client passes the transaction id from the client to the server so that any store accesses are properly enlisted to a transaction. To that end I added the generateTransactionHeader() call to the following WebdavResource module methods since they weren't enlisting themselves in the current transaction as required: subscribeMethod (both of them) unsubscribeMethod pollMethod lockMethod unlockMethod Both the lock and unlock need to be enlisted because of changes that make to the lock store but these particular methods aren't those used to start, commit and abort transactions. The transaction support interfaces construct an the lock/unlockMethod objects themselves and I haven't called generateTransactionHeader() for the transaction interfaces. Test Case: It was easy for me to reproduce with a DB2 nodestore and tx filesystem store. Enable client side transactions and attempt to lock a collection then create a child collection beneath it and unlock it. From the Slide CLI client the begin and commit commands can be used to start/end the transaction. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
