mySQL lock/unlock

Lock/unlock vil jo netop kunne lave den fejl, at der lukkes for tilgang, men koden crasher eller lign. og dermed er tilgangen lukket.
Ideen med at bruge et tidsstempel og så tjekke op i mod det, var umiddelbart også den løsning som jeg ville vælge, da den netop åbner sig selv igen, efter noget tid, hvis ikke brugeren/koden får åbnet igen.

Men lock/unlock er måske alligevel løsningen.
Fandt lige denne:

If a client connection drops, the server releases table locks held by the client. If the client reconnects, the locks will no longer be in effect. In addition, if the client had an active transaction, the server rolls back the transaction upon disconnect, and if reconnect occurs, the new session begins with autocommit enabled. For this reason, clients may wish to disable auto-reconnect. With auto-reconnect in effect, the client is not notified if reconnect occurs but any table locks or current transaction will have been lost. With auto-reconnect disabled, if the connection drops, an error occurs for the next statement issued. The client can detect the error and take appropriate action such as reacquiring the locks or redoing the transaction. See Section 24.7.13, “Controlling Automatic Reconnect Behavior”.

<ole>

Det kommer vel også meget an på, hvordan det administreres. Det er formodentlig ikke nok at låse tabellen, da den anden bruger så ikke ved, at alt det, han skriver, bliver slettet ved submit.

Du bliver nok nødt til at markere den pågældende post som låst, så man enten ikke kan åbne den for editering - eller i det mindste tydeligt viser, at der ikke kan opdateres i øjeblikket.

/mvh
</bole>

Tak for input.

Jeg har tænkt mig at prøve Lock/unlock og lave lidt tests på det. Hvis det virker halv dårligt, så benytter jeg bare timestamp.

Olebole >> Ja, den skal selvfølgelig fremgå som låst, hvis en anden bruger tilgår den pågældende besked.

Smid gerne et svar

Du får et svar!

Takker for point.