This sounds reasonable to me! Where is the patch you described? Oliver
On Mon, 15 Nov 2004 18:09:15 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
