Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

select..for update deadlock MySQL

[es] :: MySQL :: select..for update deadlock MySQL

[ Pregleda: 4999 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

mehanizamm
Vranje

Član broj: 82537
Poruke: 85
*.dynamic.isp.telekom.rs.



Profil

icon select..for update deadlock MySQL11.05.2016. u 10:07 - pre 17 meseci
OS: Microsoft Windows 7 Professional Service Pack 1
CPU: 8x Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, 3.9 GiB RAM
DB: MySQL 5.7.11
tx_isolation: READ_COMMITTED
autocommit: 0

Pravim multikorisničku aplikacuju gde postoje puno malih baza (tipa: opstina(id, naziv, korisnik, datum_vreme), sifra_delatnosti(id, naziv, korisnik, datum_vreme), atc(id, naziv), jkl(id,naziv)).
Code:

CREATE TABLE `opstina` (
  `id` int(3) unsigned zerofill NOT NULL DEFAULT '000',
  `naziv` varchar(145) DEFAULT NULL,
  `korisnik` varchar(45) DEFAULT NULL,
  `datum_vreme` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

INSERT aska_set.opstina
(id, 
naziv, 
korisnik
)
VALUES
(1,
'VRANJE',
'A');
COMMIT;


Korisnik A:
Code:

SELECT * FROM aska_set.opstina WHERE id=1 for update;

Korisnik B
Code:

SELECT * FROM aska_set.opstina WHERE id=1 for update;

Korisnik B je u deadlock

Moje pitanje, kako da iščitam da li postoji zaključavanje za id=1, i ko je izvršio zaključavanje?
Tako da obavestim korisnika B da je taj podatak uzeo na korekciju korisnik A i ne dozvolim deadlock.
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1240
*.dynamic.sbb.rs.



Profil

icon Re: select..for update deadlock MySQL11.05.2016. u 10:22 - pre 17 meseci
Koji problem rešavaš lock-ovanjem i zbog čega ga rešavaš na taj način?
 
Odgovor na temu

mehanizamm
Vranje

Član broj: 82537
Poruke: 85
*.dynamic.isp.telekom.rs.



Profil

icon Re: select..for update deadlock MySQL11.05.2016. u 10:45 - pre 17 meseci
Citat:
dusans: Koji problem rešavaš lock-ovanjem i zbog čega ga rešavaš na taj način?


Ne dozvoljavam izmenu podatka od strane više koisnika u isto vreme, tačnije ne želim da dozvolim da neko učita podatak za izmenu koji već neko drugi menja.
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 2179



Profil

icon Re: select..for update deadlock MySQL11.05.2016. u 10:51 - pre 17 meseci
^^ pravo pitanje

Svako ko je radio na razvoju database aplikacije mogao je da čuje tužnu priču o tome kako je propao neki projekat koji je koristio zaključavanje, tipa:

Magacioner je uzeo da obradi ulaz u magacin, nije pritisnuo commit, ali je otišao do grada da nešto obavi, pa knjigovodstvo do kraja dana nije moglo da knjiži.

(ili neka verzija ove priče)

Drugo, ovo nije deadlock nego lock. Deadlock bi bilo da je user A zaključao resurs A, a user B resurs B. Nakon toga, da bi završili posao, user A je hteo da zaključa resurs B a user B hteo da zaključa resurs A. E, to je deadlock.

Rešenje je, da se pročita slog, obradi u aplikaciji, a u momentu kada se želi update da se uradi select for update.
 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1240
*.dynamic.sbb.rs.



Profil

icon Re: select..for update deadlock MySQL11.05.2016. u 10:54 - pre 17 meseci
Ne znam da li je to neko uspeo da uspešno reši taj problem na taj način.
Šta kad neko otvori rekord i ode na ručak?
Lično mislim da je lock-ovanje debelo pogrešan pristup.

Ja sam obično rešavao na nekoliko načina, zavisno od konteksta:
Variajnta 1 - Update propada ukoliko je rekord promenjen u međuvremenu (first wins)
Variajnta 2 - Update ne propada bez obzira da li je rekord promenjen u međuvremenu (last wins)
Varijanta 3 - Confirm update ukoliko je rekord promenjen u međuvremenu

https://en.wikipedia.org/wiki/...ncurrency_control_in_databases
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 14294
*.dynamic.sbb.rs.

Sajt: mysql.rs


Profil

icon Re: select..for update deadlock MySQL11.05.2016. u 11:36 - pre 17 meseci
najlakse resenje ovog problema je u timeout-u! na zalost nije bas jednostavno za izvesti to lagano resenje kada je mysql u pitanju :(

innodb_lock_wait_timeout ce spreciti da B ceka "beskonacno", i sa innodb_rollback_on_timeout B moze da rolbekuje celu svoju transakciju u slucaju da failuje taj timeout, ali ne postoji 1/1 nacin da obezbedis da A traje "samo x sekundi" kada je MySQL u pitanju (ovi ozbiljniji igraci poput db2, oracledb i ekipe to vec mogu, mozda cak i psql moze ne secam se) .. e sad, za to da A traje "samo X sekundi" moras da pogledas klijent library koji koristis. Ovaj novi X protokol za MySQL je skroz asinhron tako da kod njega timeout radi skroz ok ali je to suvise novo da bi postojala sansa da to vec koristis :D ... za jdbc imas klasicne jdbc timeout propertie, za php nemam pojma, nije bilo nacina, dal sad ima, nisam bas u toku, za ruby moze ides kroz timeout klasu ne secam se sintakse proguglaj nacices odma...

obrati paznju da ti MAX_STATEMENT_TIME ne pomaze posto on prekida samo readonly select i ne afektira transakcije

dalje, postoje razliciti alati koji ti daju mogucnost da killnes dugotrajne upite i da kilnes klijente koji bleje suvise dugo ... za ovaj klasicni knjigovodstveni problem gde je magacioner otisao da poje(d)e nesto problem najcesce resava vrlo jednostavna skripta koja na svakih 15min proveri da li postoji "idle" konekcija (ne izvrsava nijedan upit) koja je idle duze od 20min i ako postoji istu ubije. automatski dobijes rollback te transakcije a magacioner to sto je krenuo da radi pa nije zavrsio u 20min mora ispocetka... obrati paznju da je to BUDZ uvek je bolje resiti to biznis logikom nego ovako, ovo treba da bude samo kao neki failback, magacioner treba da tuce u neku temp tabelu i onda kad zavrsi da se to njegovo mergeuje u real time sistem (ili ne, pa da dobije poruku da ne moze) ali 2 coveka paralelno da menjaju "interactive" datu - to je pogresna biznis logika
 
Odgovor na temu

[es] :: MySQL :: select..for update deadlock MySQL

[ Pregleda: 4999 | Odgovora: 5 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.