07. december 2004 - 15:32Der er
20 kommentarer og 2 løsninger
"sikre" transaktioner?
Hej
Jeg sidder og arbejder med nogle transaktioner og har i den henseende et par spørgsmål om samtidighed.
Mine tabeller er af typen InnoDB og så vidt jeg har forstået er disse transaction safe i deres implementering. Er det korrekt forstået?
Jeg har derudover et tilfælde hvor jeg først skriver til databasen, derefter henter information fra denne transaktion og efterfølgende skriver igen - alt dette må ikke kunne "forstyrres".
Jeg har så fundet følgende afsnit på mysql.com
"If the connection has autocommit enabled, the user can still perform a multiple-statement transaction by starting it with an explicit START TRANSACTION or BEGIN statement and ending it with COMMIT or ROLLBACK."
Er det er at forstå som at, hvis jeg explicit skriver:
START TRANSACTION # skriv # læs # skriv COMMIT
Så er dette sikkert fra problemer med at der kan skrives mens jeg læser og inden jeg skriver anden gang?
Eller er hele dette scenarie bare tåbeligt, og bør omskrives?
Jeg skal være den første til at indrømme at jeg ikke ved meget om MySQL. So bare with me :)
Men skal det forstås sådan at transaktioner som du beskriver dem, i dit første indlæg, ikke har noget med samtidighed at gøre? Men at de bare en en rollback funktion hvis et eller andet glipper undervejs? (Og dermed er mit "start transaction .... commit" overflødigt?)
Jeg har kigget på isolation level men jeg forstår ikke rigtigt hvordan jeg bruger det?
Transaktioner styrer også muligheden for forstyrrelse mellem uafhængige transaktioner, men hvordan den styrer det afhænger af transaction isolation level.
Undskyld det lige tog mig lidt tid at vende tilbage.
Jeg vil læse dit link Arne, tak for det.
Men vil ovenstående betyde at såfremt transaction level ikke er read uncommitted i en evt opsætning, så burde jeg være sikker med start transaction/commit løsningen, uden nødvendigvis at explicit sætte isolation level til serialized?
Begge løsninger virker naturligvis ved vore transaktion, men af hvorvidt de også sikrer at der ikke sker uhensigtsmæssigheder ved samtidig aktivitet, ved jeg ikke. Har i evt et forslag til hvordan man rent faktisk tester den slags?..det er unægtelig en kende uberegneligt at sige: "3, 2, 1 submit" :)
Hvis jeg skal forklare den konkrete problemstilling lidt nøjere så er det: Vi knytter en avatar med en række parametre til en bruger. Denne avatar har sin egen tabel og det har brugeren også. Idet vi opretter avataren tildeles den et 'id' (autoincremented), det er dette 'id' vi henter op igen for at skrive det ned i brugerens tabel idet han oprettes.
Jeg ved ikke om det ganske enkelt bare er en skidt måde at gøre hele det her sjask på? Og der er for så vidt ikke nogen grund til at vi ikke kan have avatarens informationer i samme tabel som brugeren, men det er den bare ikke pt.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
