You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by bu...@apache.org on 2004/11/15 18:09:15 UTC
DO NOT REPLY [Bug 32250] New: -
DB2 deadlock running with client side transactions enabled
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
Re: DO NOT REPLY [Bug 32250] New: - DB2 deadlock running with client side transactions enabled
Posted by 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