Lock Table

[Oliver Six]

deimeke_(at)_gmx.de (Dirk Deimeke) wrote on 14.12.2001 15:18:00:

>
>Hallo Oliver,
>
>> das mit dem Timestamp des Datensatzes ist an sich eine gute Idee, sie
>> hat nur den Nachteil, dass Du den User ueber die Unmoeglichkeit des
>> Speicherns erst dann informieren kannst, wenn er alle Aenderungen
>> schon gemacht hat. Im optimistischen Ansatz ist das auch korrekt, da
>> man dann davon ausgeht, dass kein Datensatz gesperrt ist. Im
>> pessimistischen Ansatz (und den verfolge ich meistens, da meine User
>> gemeinsam an Projekten arbeiten, die eine gewisse Datenmenge umfassen
>> und die einzelnen Datensaetze auch oft einen Umfang von 50 oder mehr
>> Feldern haben) springen Dir die User an den Hals, wenn Sie erst
>> nachdem sie 20 Felder geaendert haben, gesagt bekommen, dass das
>> nicht speicherbar ist. Deswegen mein Ansatz mit der Sperrtabelle, die
>> ich dann natuerlich bei Aenderungen mit einem 'lock table' belege.
>
>klar, wobei das im Worst Case natürlich dazu führen kann, daß ein  
>Datensatz einen ganzen Arbeitstag gesperrt ist ... oder entsprechend.
>
>Oder hebst Du den Lock nach einer vordefinierten Zeit wieder auf?
>
Hi Dirk,

ich mache das Ganze noch etwas komplizierter: Jeder Client loescht in dem 
Moment, in dem er exklusiven Zugriff auf die Sperrentabelle erhaelt, alle 
Locks, die aelter als 5 min. sind. In meinen Applikationen habe ich dann 
einen Timer, der ca. alle 2 min. kommt und einen Refresh (Update der 
Lockzeit) auf seine eigenen Locks faehrt. Damit erreiche ich, dass alle 
Datensatze max. 5 min. laenger als noetig gesperrt sind, was sich bei einem 
Absturz eines Clients als vertretbare Zeit herausgestellt hat. 

Ciao Oliver
--
Good programming is 40% experience, 30% skill, 20% RTFM, 10% caffeine, and 
5% attention to detail. 

Oliver Six, CEO
CAHOS GmbH, Cimbernstr. 51, Germany 81377 Muenchen
Phone +49 89 71 01 93 40,  Fax +49 89 71 01 93 41

---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql