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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Windows 2000 |All ------- Additional Comments From [EMAIL PROTECTED] 2004-11-15 22:03 ------- On the first comment: I added subscribe, unsubscribe and poll for two reasons. First, they all call the AbstractWebdavMethod.run() which means that they will all perform the structure.retrieve() and unlock cleanup code which both go out to the store. If they aren't enlisted in a transaction then they lock up the DB2 client. Secondly, even if we modified the run() method not to call these methods for subscribe, unsubscribe and poll, could we be sure that these methods will never want to store or fetch data from a nodestore at some time? It is safer to enlist them to the current transaction just to be sure and there's no harm to wrapping them in a transaction. Now for the Lock and Unlock methods: They both must be enlisted to the current transaction so that the locks will be released on the server if the transaction fails. They are like any other method call in that they make modifications to the stores that should only be comitted when the transaction is committed in its entirety. Now given this the server side LockMethod and UnlockMethod do perform the dual role of doing normal resource lock/unlocks as well as implementing transaction- based locking. Transaction based lock method calls cannot be enlisted in the current transaction because the startTransaction() can't be nested within another transaction and must be called to create a new transaction. Similarly the commit/abort commands can't be enlisted to the current transaction or the commit will fail noting that the transaction is in an invalid state. I have tried a number of variations of enlisting and not enlisting the lock/unlock methods to the current transaction and the above is the only one that works correctly and makes the most sense given that LockMethod/UnlockMethod on the server perform a dual role of normal resource locking plus a locking role to denote the start/end of a transaction each of which must be treated separately as far as their enlistment to the current transaction goes. -- 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]
