[Mysql][PHP] Tabellen "locken"

[Verwijderd]

k zal er wel weer niks van snappen, maar ik kan het ook echt nergens vinden. Overal waar ik zoek op internet gaat het over vanalles behalve datgene wat ik zoek. Dat is namelijk het volgende:

Ik heb een programmaatje geschreven in PHP met een mysql-database erachter, dit programmaatje wordt gebruikt door verschillende gebruikers met dezelfde rechten. Nu is het noodzakelijk dat er niet twee gebruikers op hetzelfde moment gegevens kunnen wijzigen in de tabellen. Je snapt zelf wel waarom...

Ik heb gezocht op Google etc naar iets als Mysql multiple users, tabellen locken, en allerlei combinaties hiervan. Ik heb eigenlijk geen idee hoe het zou kunnen, heel misschien door het aanmaken van verschillende gebruikers, maar ik kan me niet voorstellen dat het dan al klaar is.. Kan iemand me aub helpen?

Chris

[Alex]

Tablelocking is iets wat er door MySQL zelf gebeurd. Je kutn dit wel simuleren.
Bijv een row in je table zetten die heet `edit` en als er iemand dat deel gaat bewerken zet je hem op 1. En zeg je tegen de volgende dat hij dat deel niet mag bewerken.

[Verwijderd]

Maar als ik het goed begrijp geeft Mysql zelf al een melding als je met z'n tweeen tegelijk de rij in de tabel bewerkt? Moeten dit dan verschillende Mysql-users zijn?

[Verwijderd]

Kijk stel gebruiker 1 gaat de gegevens van een auto in het systeem aanpassen. hij vraagt de auto op en gaat de gegevens wijzigen.. Ondertussen doet gebruiker2 hetzelfde. gebruiker1 slaat hem op (pas nu gaat Mysql hem invullen en zal ook nu pas locken denk ik??) Daarna slaat 2 hem op (is niet meer gelocked neem ik aan) en dan zijn de gegevens van 1 mooi weg... Het kan inderdaad met een extra kollom, maar ik heb 56 tabellen en het is aardig wat werk om dat allemaal aan te gaan passen... Krijg meerdere fouten in mijn systeem omdat ik de kolommen aanroep met de cijfers ($row[3] enzo)

Kan het niet anders??

Daarbij komt overigens ook nog dat als ik een fout op de pagina zou krijgen of op tyerug zou klikken in internetexplorer dat de tabel dan gelocked blijft.

[ Voor 12% gewijzigd door Verwijderd op 30-12-2002 18:09 ]

[ACM]

Zie de mysql-manual voor table-locking.

Domweg zoiets uitvoeren:
lock table X etc;
select ... blabla;
....
update blabla;

en dan afhankelijk van je lock-parameters
unlock table;

enzovoorts. Mysql ondersteund het dus expliciet en doet het sowieso impliciet, maar dat is inderdaad maar heel kort.

[eXtReMeBiE]

Hier was volgens mij een heeeele tijd terug ook al een topic over, en dit werd de topicstarter toen verteld:

Waarom maak je niet een extra tabel aan met daarin de id's van de pagina's, vervolgens een 1 erin schrijft als iemand de edit-pagina bezoekt, en een 0 als hij de data heeft verstuurd.
Als gebruiker 2 dan probeert te editen, terwijl gebruiker 1 bezig is, krijgt hij een error message, omdat bij het id van de pagina die hij wil editen, een '1' in de tabel staat...
Het kan dus ook met een extra row (veel simpeler en kleiner dus dan een extra tabel met id etc) waar je 1 en 0 ofzo in schrijft.

[ Voor 7% gewijzigd door eXtReMeBiE op 30-12-2002 20:08 . Reden: wat typo's ]

[Verwijderd]

Ok, dat werkt allemaal wel, maar als gebruiker1 nou terwijl hij een edit pagina open heeft zijn browser afsluit of op back drukt, of iets dergelijks, staat de tabel dus nog steeds gelocked en kan een andere gebruiker er dus noooooit meer in. Tenzij de gebruiker1 hem weer unlocked door weer de pagina te openen en hem dan op normale wijze te sluiten.

Dit is niet wenselijk. Iemand Ideeen???

thnx

[SuperRembo]

Je kunt ook bij het updaten controleren of de gegevens gewijzigd zijn.

SELECT id, veld1, veld2 FROM tabel WHERE id=$id

gebruiker wijzigt gegevens ...

UPDATE table SET veld1=$veld1, veld2=$veld2 WHERE id=$id AND veld1=$oldveld1 AND veld2=$oldveld2

Als een andere gebruiker ondertussen de gegevens in de tabel gewijzigd heeft dan worden die wijzigingen niet overschreven. Je moet achteraf natuurlijk wel controleren of de update wel of niet is uitgevoerd en dat eventueel terugkoppelen naar de gebruiker. Je krijgt wel erg grote update statements, zeker als velden null mogen zijn. Dit heeft optimistic concurrency als ik het goed heb.

[goalgetter]

Heel simpel te verhelpen... InnoDB met row-level locks gebruiken.
De andere oplossing is de table locken voor de select, en pas unlocken na de update aangezien je anders een update anomalie kan krijgen. (user 1 vraagt gegevens op, user 2 ook, user 1 voert update uit, user 2 voert update op basis van OUDE gegevens uit => update user 1 verloren).
Nu wil je niet dat je hele table gelocked moet worden in een multi-user omgeving aangezien dan niemand anders kan lezen/schrijven in die table zolang er een transactie gaande is, dus gebruik je InnoDB met een row-level lock zodat iedereen vrolijk kan doorwerken behalve op de gegevens die gewijzigd moeten worden.

[ACM]

[nohtml]

goalgetter schreef op 31 december 2002 @ 15:27:
Heel simpel te verhelpen... InnoDB met row-level locks gebruiken.

Dat is geen oplossing hiervoor, ga zelf maar na waarom niet en leg anders beter uit hoe je zoiets kan locken met de innodb locking...

Bij mijn weten kan je iig niet zomaar een record locken in mysql, of wel?

[goalgetter]

Jawel, en dat kan alleen maar met InnoDB (correct me if I'm wrong). InnoDB is de enige manier waarop je in mysql transacties kan doen en row-level locks kan doen (oftewel record locks).
http://www.innodb.com/features.html

Locking:
consistent read of Oracle implemented: the database is multiversioned and readers can read old data setting no locks, and thus not delaying updates; multiversioning is achieved through 'rollback segments' like in Oracle, but in the InnoDB implementation there should not be similar problems with them as in Oracle;
row level locks which fit in a small space: no lock escalation needed;
next-key locking used: no 'phantoms' occur, and transactions are serializable, thus better than in Oracle;
table level locks;
automatic deadlock detection;
lock monitor helps diagnosing application locking problems;
semaphore contention reduced by several methods.

[ Voor 65% gewijzigd door goalgetter op 31-12-2002 16:15 ]

[ACM]

Rowlevel locking voor het verwerken van de commando's is wat anders dan het expliciet locken van tables door de gebruiker.

Zie hier http://www.mysql.com/doc/en/LOCK_TABLES.html over dat laatste

[goalgetter]

Praten we nou langs elkaar heen of is er iets wat ik over het hoofd zie... Natuurlijk is een expliciete table lock anders dan een automatische (impliciete) lock.

Als gebruiker start je (in het InnoDB scenario) gewoon een transactie en vraag je de locks expliciet aan.

vb:
SELECT ... FROM ... FOR UPDATE : sets exclusive locks on all index records the read encounters.

Aangezien InnoDB nogal wat features heeft die niet in de standaard mysql table type's voorkomen moet je wel bij de InnoDB docs kijken. Om wat meer over InnoDB behaviour met betrekking tot locks en transactions te lezen kijk hier.