Hi Oliver, > There should be no locks created by startTransaction() and > endTransaction(). Or are you talking about the locks created > inside the transaction?
Internally to the server there are no locks created but it returns a lock token for transaction LockMethode call and this token is stored in the webdav clients lock cache as if it is a lock. The client thinks it is an actual lock and adds it to its lock cache as such. That's why I'm wondering whether the locks ids (tx ids) that come back from the server should be ignored by the client when it processes the result of a LockMethod. Ie. in the startTransaction() call once we have the tx id and store it when then delete the equivalent lock created for it from the client lock cache. > > Otherwise they will show up as normal locks when they are actually > > implemented internally by the slide server. > ?? I mean to say that the client sees them as "normal" locks as it has lock tokens for them in its cache when there is no real corresponding lock on the server. And its passing these tx ids back to the server as locks tokens in the "if" header. What are your thoughts on the other points? Warwick > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 14, 2004 3:49 AM > To: Slide Users Mailing List > Subject: Re: A few webdav client locking concerns > > > On Mon, 13 Dec 2004 16:49:11 -0800, Warwick Burrows > <[EMAIL PROTECTED]> wrote: > > 4. Transaction locks are being stored alongside normal > locks. ie. the > > locks that are created using startTransaction() and > endTransaction() > > are kept in the same client lock cache as other locks which is what > > spurred my questions > > There should be no locks created by startTransaction() and > endTransaction(). Or are you talking about the locks created > inside the transaction? > > > above. The getAllLocks() function is returning this special > lock and > > adding it to every "if" header sent to the server. But this > may only > > be a problem because the processing of transaction locks is handled > > alongside every other lock in the parseResponse*() methods of the > > LockMethod/UnlockMethod. Seeing that the call to LockMethod > made from > > the startTransaction() method doesn't add the lock to the > client lock > > cache with addLock() like the lockMethods() do and the lock > token is > > in fact kept in a "transactionHandle" variable used exclusively to > > generate the transaction header, I believe that the > transaction locks > > shouldn't be stored in the client cache with other locks. > > What transaction locks? The transactional control only > "misuses" the LOCK/UNLOCK method to actually start/end a > transaction. No locks are involved... > > > Otherwise they will show up as normal locks when they are actually > > implemented internally by the slide server. > > ??? > > Oliver > > --------------------------------------------------------------------- > 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]
