[TinyOWS-users] [TinyOWS-dev] WFS Transaction locks

[Rahkonen Jukka]

Hi,

Olivier,

>>As i understand the spec, there's two phases,
>>one to lock (LockFeature), one another (Transaction) to apply transaction(s)
>>And you could should to release Lock at the end of a/the Transaction,
>>or wait till the end of the time limit.

> Before the start of the transaction, you must call EnableLongTransactions() to create the required autorization table, then call CheckAuth() to create the trigger on the specified table and finally call for LockRow to lock row by row. Later, the transaction begins and the first thing to do is call AddAuth() to lock the table just within transaction, once COMMIT or ROLLBACK is issued, the changes made by AddAuth are removed automaitcally.. Later you have to call UnlockRows to release all the locks in one step, and call DisableLongTransactions to drop all the triggers that was created.

WIth releaseAction=ALL all the locks tied to the same lockID must be released but if the policy is releaseAction=SOME you must release the edited rows but keep the non-edited ones locked, with the timer set to zero to start counting a new expiry time.

>>So operation must fails if:
>>- LockFeature is requested with LOCKACTION=ALL and not able
>>  to lock alls.
Server must not send any feature at all in this case

> Ok, that's what I thought. What if TinyOWS could add to the transaction summary those features that couldn't be affected ?
With lockaction=all the response can only be an error message. With lockaction=some server must send locked and unlocked features as separate sets.

>>- Transaction is requested on an already locked feature.
> Mmmmm ... what about some SLEEP function to wait for the feature availability ? This reduces the communication payload.
I do not believe this would work because client must get a new valid lockID from the server with LockFeature or by GetFeatureWithLock first.

>>The WFS way to do it, is to handle feature by feature,
>>so row by row for the undelying spatial database seems fine.
>>Lock by table, is indeed only a (very) specific use case.
> Agree, locking a table is not so efficient (but easiest to implement ;))

>>Some others thoughts,
>>- DefaultLockExpiry should be set by default to a reasonable small value

>When you call for AddAuth, you can specify a time limit. PostGIS default is 1 hour (to much for me) so I'm thinking to set it (maximum) 10 minutes. However, this must be configurable at
tinyows.xml or tinyows.map.

It can be configured also by the client. 10 minutes might be good. But it must be remembered that after that period it is not possible to save the edited feature with the old lockID. It might be frustrated for someone who has been editing 11 minutes without saving. It is possible to get a new lockID with lockFeature request and not to loose the edited work, though.

>>- A boolean should be set in the config file to activate yes or no,
>> the lock support

> Ok, yes by default ?
No, no by default.  I do not know of any open source editor (or other) that handles locking and if I have understood it right, if locking is enabled it is not possible to edit without locks.

>>- What about a way to release one/all locks from administrator point of view ?
> You can always call UnlockRows to remove the locks, so we can set this in a function to be able to be called by the transaction process or by an administrator.
It is a necessary feature and administrator must have some means for releasing the locks.  It would not make much sense if WFS users could free the locks of other users. WFS does not seem to contain any ReleaseLock action and lock can only be released by doing a transaction or by waiting till the expiry time has elapsed.

My opinion is that the WFS locking mechanism may be suitable for some use cases but it is not extraordinary good at all. I suppose it could suit for fast editing of individual features like points of interest if the work flow is
- Get a few feature with strict attribute or area filter
- Edit within a minute or two
- Save

However, WFS locking does not necessarily suit well for editing something like parcel coverage, especially if and if digitisers are working on the same area. Sometimes editing may be fast but sometimes it can take an hour to edit an area . Users may lock unnecessary many features because they must see also the neighbouring parcels and prevent others from editing. On the other hand features may have been released due to expiry time before user is ready for saving the edits. Repeating lockFeature may not help because another user could have locked it already. But is is not easy to make a general feature locking system that would make everybody happy. Many concurrent users editing uncontrolled with plain WFS-T is not a good solution either.

-Jukka Rahkonen-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-users/attachments/20110923/551bc759/attachment.htm