Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Standard Techniques for Distributed Applications
Message
 
À
17/05/2001 13:10:52
Information générale
Forum:
Visual FoxPro
Catégorie:
Applications Internet
Divers
Thread ID:
00508412
Message ID:
00508601
Vues:
23
I use Web-Connection, but you can implement a similar method. WWC has sessions for identifying users, which time out after x seconds (1800 by default). If you want pessimistic locking, store the value of the user's sessionID in a field indicating that the record is locked. Then you can...

Another user tries to edit:
1. Field is blank --> OK
2. Field is not blank but sessionID = user's SessionID --> OK
3. Field is not blank, sessionID <> user's sessionID...
.3a if sessionID has timed out -->OK
.3b if sessionID is still valid --> FAIL

With the exception of 3b, the record's sessionID then needs to be set to the user's sessionID.
This works well as any users that crash out (or close their screen during editing) only lock records for a maximum of x seconds.

This sounds clunkier than it is (I had a user who insisted on pessimistic locking) and is still VERY fast: you usually have only one copy of the server and it's practically working single-user. I use classes for data access so it can be built in at that level leaving your process code reasonably clean.

If you can persuade your users, try using optimistic locking instead.


In most applications, at some point you have a list of records from which you can choose a record to edit. Clearing a user's locks can be done when presenting the list (i.e. if you are reading the list, you are not reading any records).


>My concern lies in the area of implementing some of the standard operations that a user would expect to use in a normal application. For example ... Adding a new record: That seems rather simple ... check for duplication and if none, add it to the database. Editing Records: That seems more complicated. Do I put some sort of FLAG in the record to indicated that it is being edited and only allow 1 editor on the record ? This seems ok. However, what if the editor drops dead and never comes back to the server? I suppose I could come up with some sort of timing routine to open the record up again after a given period but that seems rather clunky ...
>
>I would be interested in hearing from someone with firsthand experience with this. Ideas are fine but until actually implemented they fall short of a real-life solution.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform