Re: DO NOT REPLY [Bug 32250] New: - DB2 deadlock running with client side transactions enabled

[Oliver Zeigermann <ol...@gmail.com>]

This sounds reasonable to me! Where is the patch you described?

Oliver


On Mon, 15 Nov 2004 18:09:15 +0100, bugzilla@apache.org
<bu...@apache.org> 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: slide-dev@jakarta.apache.org
>         ReportedBy: wburrows@e2open.com
> 
> 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: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org