Lock Table

[Oliver Six]

deimeke_(at)_gmx.de (Dirk Deimeke) wrote on 14.12.2001 14:42:00:

>
>Hallo Oliver,
>
>> Das einzige Problem, wo Du ein explizites Locking selber machen musst
>> (ob nun ueber 'lock table' oder eine selbst organisierte
>> Sperrtabelle), stellt die Bearbeitung eines Datensatzes (per Select
>> und spaeterem Update) auf mehr als einer Client-Maschine dar.
>
>das macht ja auch Sinn.
>
>Muß man tatsächlich die ganze Tabelle sperren oder kann man auch einen  
>einzelnen Datensatz sperren?
>
>Ich überlege gerade, ob es nicht mehr Sinn macht, vor dem Speichern den  
>Timestamp des Datensatzes zu vergleichen ...
>

Hi Dirk,

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. 

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