Sanity check of transaction support fixes

[Warwick Burrows <wa...@e2open.com>]

Hi guys,

I'd like to ask those who know/use/care about the WebDAV client transaction
support to sanity check some fixes I've made to Slide (client and server) to
get transaction continuation from the client to the server working.  I've
submitted the patch deltas to bugzilla along with defect number 32250.

The problem I found was 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.

Warwick

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