<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="GENERATOR" content="MSHTML 8.00.6001.19120">
</head>
<body>
<div><font size="2" face="Arial"><span class="185533409-23092011">Hi,</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">Olivier,</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>As i understand the spec, there's two phases,<br>
>>one to lock (LockFeature), one another (Transaction) to apply transaction(s)<br>
>>And you could should to release Lock at the end of a/the Transaction,<br>
>>or wait till the end of the time limit.</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> 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.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">WIth releaseAction=ALL all the locks tied to the same lockID must be released b</span></font><font size="2" face="Arial"><span class="185533409-23092011">ut 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.</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>So operation must fails if:<br>
>>- LockFeature is requested with LOCKACTION=ALL and not able<br>
>> to lock alls.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">
<div><span class="185533409-23092011"><font size="2" face="Arial">Server must not send any feature at all in this case</font></span></div>
</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> Ok, that's what I thought. What if TinyOWS could add to the transaction summary those features that couldn't be affected ?</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">
<div><span class="185533409-23092011"><font size="2" face="Arial">With lockaction=all the response can only be an error message. With lockaction=some server must send locked and unlocked features as separate sets.</font></span></div>
<div><span class="185533409-23092011"></span> </div>
</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>- Transaction is requested on an already locked feature.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> Mmmmm ... what about some SLEEP function to wait for the feature availability ? This reduces the communication payload.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">
<div><span class="185533409-23092011"><font size="2" face="Arial">I do not believe this would work because client must get a new valid lockID from the server with LockFeature or by GetFeatureWithLock first.</font></span></div>
</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>The WFS way to do it, is to handle feature by feature,<br>
>>so row by row for the undelying spatial database seems fine.<br>
>>Lock by table, is indeed only a (very) specific use case.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> Agree, locking a table is not so efficient (but easiest to implement ;))</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>Some others thoughts,<br>
>>- DefaultLockExpiry should be set by default to a reasonable small value</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>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
</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">tinyows.xml or tinyows.map.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">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.</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>- A boolean should be set in the config file to activate yes or no,<br>
>> the lock support</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> Ok, yes by default ?</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">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.</span></font></div>
<div><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">>>- What about a way to release one/all locks from administrator point of view ?</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">> 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.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">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. </span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">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</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">- Get a few feature with strict attribute or area filter</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">- Edit within a minute or two</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011">- Save</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">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.</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011">-Jukka Rahkonen-</span></font></div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font><font size="2" face="Arial"></font> </div>
<div><font size="2" face="Arial"><span class="185533409-23092011"></span></font> </div>
</body>
</html>