On 23/02/2006, at 5:00, "Jonathan Lynch" <[EMAIL PROTECTED]> wrote:
any other tips?
Rob's comment about supporting 15-30 users is valid although it depends also on the transaction rates they can achieve.
Jim's discussion of pre-emptive rights for certain actions or user types will add complexity to the locking and checking process. My own view is that I would adopt a real client-server database if I were going to that level. Given we are talking about a small system and user base, pre-emption should not be critical. We are relying on a process to give up a lock anyway, which is something else you should consider (removing stale locks where a process has died or improperly quit). Jim's general strategy of reserving line 1 for metadata is very nice. I would stick to flags for locking, though, simply for the small speed gain.
To create a flag, generate a random number and create a file of that name .flag. To see if you can go ahead, first count the number of flag files and, if one, check that it is yours. Remember to remove the flag under all exit conditions and consider the tradeoffs of a cleanup daemon which arbitrarily removes flags older than X, where X is entirely your problem in your context :-). At the least you should be able to post a warning message.
Finally, you may need to time your flag setting/checking loop under various conditions so you can set a safe minimum wait time to avoid races while the maximum does not delay processing too much. We should be talking a range of milliseconds.
HTH regards David _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
