Thursday, September 25, 2008, 10:44:39 PM, Patrick wrote: > Before doing any processing that might modify pages, call > Lock(2). If you're reading from a page for a value that > will be later be used as part of an update, then you want to > Lock(2) prior to the read, not only during the write. This > way other processes that might be doing read-process-update > will block prior to their reads, giving the current process > a chance to finish doing its updates.
that was my thinking too, but it seems not to be quite sufficient. A PmWiki admin who uses Fox forms came to me with this problem. I have recreated a table row posting form on a testwiki: http://softflow.org/testwiki?n=Test.TableForm edit (and posting) access password is: test This form calls a foxfilter function, which the fox script processes early on, after getting initial input and data. This custom function calls Lock(2), and also flushes the page cache, as I thought PTVs are kept in cache and it might be better to prevent reading from cache. The function processes the input data array $fx, and goes like this: $FoxFilterFunctions['IncRow'] = 'IncreaseRowFilter'; function IncreaseRowFilter($pagename, $fx) { global $PCache; if (@$PCache[$pagename]) unset($PCache[$pagename]); Lock(2); # get PTV 'row' and add 1 $fx['ptv_row'] = $fx['row'] = PageTextVar($pagename, 'row')+1; return $fx; } If you look at http://softflow.org/testwiki?n=Test.TableForm you see what looks like duplicated rows numbered 18 and 36. The posted content is actually not identical, both should show different colors, but since the row number posted in both are the same, the PTV values displayed are identical. Rows 33 and 34 carry the same input time (same to the second), so you see that input needs to be very nearly simultaneous in order to produce this error of duplicate row id numbers. The problem is worse on a system with a slow server, which is the reason the admin noticed this on his setup, which includes a VPN. Is there some other way to improve the situation to disable near-simultaneous input? Hans _______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel