Record Locking op het Web

[bram]

Enig idee hoe je dit kunt oplossen.

Op het web werken we niet real-time. In geen enkele toepassing/database.

Een "browser" vraagt info aan de database, die komt in een formulier, en kan de aangepaste info terugsturen om te bewaren in een database.

Probleem stelt zich als een tweede bezoeker zich aanmeldt.

 

Dan krijg je dit:

Bezoeker 1: Vraag info op (A, B, C)

Bezoeker 2: Vraagt info aan server (Krijgt A,B,C)

Bezoeker 2 (is sneller) en schrijft naar de database: (A1, B, C)

Bezoeker 1 drukt submit na de aanpassing en schrijft: (A, B1, C)

 

Dus de aanpassing van bezoeker 2 is overschreven omdat bezoeker 1 te traag was.

 

Je zou dit kunnen oplossen door per record een veld bij te houden dat op "lock" wordt gezet als een bezoeker de info opgevraagd heeft om te updaten.

En de "lock" wordt er af gehaald als de update geschreven is.

 

Probleem is, wat als de bezoeker gewoon niet verder doet, of de sessie verloopt.

Dan blijft het record gelockt.

 

Dan zou je kunnen een script laten lopen dat om de x aantal seconden alle records zoekt die "lock"-ed staan, en waarvan de lock ook ouder is dan x minuten (vb de duur van je sessie time-out) en die records worden dan terug vrijgegeven. Maar daar zijn nadelen aan. Bijvoorbeeld dat records lang kunnen gelocked staan...

Dus: ik vind dit geen elegante oplossing.

 

Iemand een geniaal idee?

[Kermit]

Eigenlijk is dit een complexe materie om dit zelf te coderen. Het feit is dat je ook realtime rekening moet houden met de gebruikers-databank. Daar moet ook ingesteld worden wanneer ze een laatste actie hebben gedaan.

In het record dat bewerkt wordt, moet eveneens staan welke gebruiker de laatste actie heeft gedaan en op welk tijdstip.

Deze twee waarden (het echte record en de gegevens van de gebruiker) moeten met elkaar vergeleken worden.

Ik ben er ook al een tijdje naar aan het zoeken, en ik heb al een aantal testjes liggen.

De reden waarom je dit vraagt is vooral voor MySQL neem ik aan? Ik heb gisterenavond gelezen dat MySQL 4.0 uit is, mét row-locking! Hoe dit precies in elkaar zit, moet ik nog even nakijken. Let wel, MySQL 4 is nog in beta, en is niet in de Lasso-applicatie geïntegreerd! Lasso laat natuurlijk wel toe om een externe MySQL-databank te gebruiken.

[Koen Van Hulle]

Als het toch voor FileMaker mocht zijn...

 

Gebruik record-locking voor een bepaalde periode, m.a.w hou de datum en tijd bij waarop de gebruiker je record gelocked heeft, en baseer je record locking op een calculatie hiervan.

 

Stel dat eens sessie vb maximum 20 minuten duurt, dan kan het record dus maximum 20 minuten gelocked worden. Onderbreekt een bezoeker zijn sessie, dan kan de volgende bezoeker 20 minuten nadien toch het record editeren. Baseer dus de locking niet op een vlag, maar op een combinatie van tijd, datum (van de server uiteraard) en gebruiker (kan evt IP-nr zijn).

 

Ik heb iets dergelijks al geimplementeerd bij een FileMaker applicatie (niet web) om een set van records tijdelijk te locken en dit werkte feilloos. Ik denk dat de factor web niet echt meespeelt als je een sleutel hebt voor de gebruiker (IP is niet altijd correct, er kunnen problemen zijn met proxy-servers e.d.)

 

Groeten,

 

Koen

[Kermit]

Dat is dus hetgeen dat ik ook wil zeggen.

Ik wil wel eens jouw oplossing zien, Koen. Zo kan ik nagaan of we hierbij eenzelfde oplossing hebben gevonden, of dat er toch nog verschillen in zijn.

Ik maak gebruik van een gebruikersdatabase, een gebruikersid-vermelding in het te bewerken record, de tijd waarop de gebruiker deze bewerking aangevraagd heeft en de tijd van de laatste actie van die gebruiker.

[Koen Van Hulle]

Ik hou het bij bij het record zelf. De record locking gebeurt via de ingebouwde FileMaker Record Locking Security (vanaf 5.5) en een scriptje.

 

Koen

[Peter Wagemans]

Misschien nog even in de thread gooien, niemand vermeld dit immers:

 

Status (CurrentRecordModificationCount)

[bram]

Thierry heeft me laatst DE tip aan de hand gedaan, en die komt redelijk overeen met het idee wat Peter gaf in zijn laatste bericht.

Probleem is dat er geen (RecordModificationCount) bestaat in MySQL. Maar wel een timestamp.

Dus als je het record opvraagt voor "lezen" lees je ook de TimeStamp mee uit.

Als de tweede gebruiker sneller was dan jij, is de timestamp aangepast sinds de laatste schrijf actie.

Dus dan moet je in de code inbouwen dat er iets moet gebeuren.

Bijvoorbeeld keuze laten tussen overschrijven, of recente data terug uitlezen en tonen aan de bezoeker.

Voila.