Srodne teme

30.12.2004. Distributed Application
08.04.2005. HP307.Razlozi protiv?
14.04.2005. Odredjivanje broja dokumenta u multiuser okruzenju
27.09.2005. Forum i Knjiga gosiju na zakljuvavanje ?
06.06.2006. Zakljucavanje fajla???
17.10.2006. Razlozi zaledjivanja ekrana
07.11.2006. w810i zakljucavanje foldera ?
02.12.2006. Panasonic KXTA61610B
15.04.2007. Zakljucavanje tastature i misa...
08.04.2007. Galeb G-4 catia model, Kako vam se dopada?

Navigacija

Brisanje liste

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

Pesimisticko zakljucavanje - razlozi za i protiv

[es] :: MS SQL :: Pesimisticko zakljucavanje - razlozi za i protiv

[ Pregleda: 3916 | Odgovora: 15 ] > FB > Twit

Autor

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Pesimisticko zakljucavanje - razlozi za i protiv

^{06.02.2009. u 09:13 - pre 197 meseci}

Molim za vaše mišljenje.

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{11.02.2009. u 13:43 - pre 197 meseci}

Bilo je dosta pisanja kako je pesimističko zaključavanje glupost, kako srozava perfomanse aplikacije, i još dosta drugih neistina ili delimičnih istina. Čak su i mlađi članovi, sa malo iskustva, prihvatili to zdravo za gotovo. Neko od njih je napisao da je pesimističko zaključavanje daleka prošlost jer se i Microsoft opredelio za optimizam i odustao od pesimizma. A zaboravlja se da čak i Microsoft koristi transakcije i trigere koji po definicij zaključavaju podatke koji učestvuju u transakciji ( i triger je transakcija). Očekivao sam da se malo ozbiljniji programeri jave i da proširimo diskusiju na tu temu.

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Baze podataka i konkurentnost rada

^{11.02.2009. u 17:10 - pre 197 meseci}

Ako krenes tom uproscenom logikom onda optimisticki concurrency ni ne postoji jer ce se na kraju sve svesti na U, IX, X sekvencu lockova tokom update/insert komande i njihovu propagaciju tokom serijalizovane transakcije.

Problem nije u postojanju X lockova, problem je u pristupu resavanju svih mogucih concurrency problema na aplikativnom nivou kroz pesimisticne lokove i bahatom ponasanju i drzanju lockova proizvoljno vreme kao da je trenutna skripta jedina na svetu uz jos bahatije objasnjenje da nema toliko korisnika na sistemu. I ne znam zasto ocekujes drugacije obrazlozenje? Postoje aspekti u kojima nije moguce zaobici pesimitcne lokove (kao npr u two-way distributed transakcijama), ali za sve otalo postoji adekvatnije i skalabilnije resenje. Zasto je to vazno procitaj u drugoj poruci koju si otvorio, da se ne ponavljam na dva mesta.

Nisu samo klijenti koji aktivno azuriraju bazu smetnja, zapravo oni su retko kad smetnja jedni drugima jer obicno manjaju razlicite redove u tabelama i ne-eskalirani RID lock je sasvim dovoljan da ih razgranici i da im omoguci konkurentan rad.
Ono sto je mnogo veci problem su svi ostali korisnici sistema koji imaju potrebu da cesto citaju te tabele i redove, a citanje (SELECT) nije potpuno pasivna operacija narocito kad je SERIALIZABLE izolacija u pitanju. Da bi select vratio redove mora da uspostavi IS, S (intended share pa share) lock nad SVIM redovima koje vraca, i ako neki drugi proces(i) drze U, IX, X (update, intended exclusive, exclusive) lockove nad tim redovima select mora da ode u WAIT za SVAKI od njih (ili da eskalira lock u PAGE/TAB i opet da ceka na WAITu) i za svaki mora da se izlakta drzeci IS lock nad njima tako zaustavljajuci IU, U, IX, X pokusaje iz nadolazecih update operacija koje sad moraju da cekaju na U locku da se select kompletira. Ako usput naidju i drugi select-i i oni se ubace u zajednicko cekanje na S lock. Dakle sad ne govorimo o 100 korisnika koji rade paraleleni update, vec o 100 korisnika koji rade select nad opsegom u kome se nalaze X lockovi koje drze drugi procesi, a ti korisnici vise nisu samo pera, mika i zika, to su i automatski servisi i procesi koji rade pozadinske poslove, stampu, validaciju, itd, itd.

Jel sad jasnije zasto ne treba produzavati X lock duze nego sto je apsolutno neophodno i zasto se pesimistic lockovanje ne skalira lepo i zasto ga ne treba koristiti bez preke potrebe?

[mod: konsolidovao dve poruke u jednu]

_{[Ovu poruku je menjao mmix dana 12.02.2009. u 13:57 GMT+1]}

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 10:55 - pre 197 meseci}

Citat:

mmix:
...
problem je u pristupu resavanju svih mogucih concurrency problema na aplikativnom nivou kroz pesimisticne lokove i bahatom ponasanju i drzanju lockova proizvoljno vreme kao da je trenutna skripta jedina na svetu uz jos bahatije objasnjenje da nema toliko korisnika na sistemu. I ne znam zasto ocekujes drugacije obrazlozenje?
...

Za početak citiraću autore knjige SQL server 2000 Mike Gunderloy i Joseph L. Jorden

Citat:

...
Baze podataka koje dozvoljavju da više korisnika istovremeno menja podatke moraju imati određen mehanizam koji će obezbediti da te promene ne naruše konzistentnost baze. Mnoge baze u tu svrhu koriste zaključavanje koje se ponekad naziva i blokada pristupa.
...
U gotovo svim situacijama SQL server koristi pesimističku kontrolu istovremenog pristupa podacima.
...

Vidiš, isti a možda i veći problem je kada se u rešavanju svih mogućih problema konkurencije koristi optimistički pristup (neću da ponavljam priču o bahatosti). Cilj ove teme je da pokuša da pokaže u kojim situacijama je opravdano i jedino moguće pesimističko zaključavanje i na koji način ga primeniti, a ne propagirati ga kao jedino ispravno. U naslovu teme lepo piše: razlozi za i protiv

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 13:18 - pre 197 meseci}

Citat:

mkaras: Vidiš, isti a možda i veći problem je kada se u rešavanju svih mogućih problema konkurencije koristi optimistički pristup (neću da ponavljam priču o bahatosti). Cilj ove teme je da pokuša da pokaže u kojim situacijama je opravdano i jedino moguće pesimističko zaključavanje i na koji način ga primeniti, a ne propagirati ga kao jedino ispravno. U naslovu teme lepo piše: razlozi za i protiv

Ok, ja sam izneo konkretan razlog zasto je drzanje pesimistickog locka lose (doduse u drugoj temi, ali sad sam tu poruku prebacio ovamo gde joj je mesto, pa procitaj ponovo gore). Koje je tvoje objasnjenje zasto je optimistic lock los i losiji od dugotrajnog drzanja X locka?

I ne da u "gotovo svim" vec u "apsolutno svim" situacijama SQL sever koristi pesimisticki lock, nijedan update i insert se nece desiti pre nego sto se uspostavi X lock nad odgovarajucom granulacijom, u najkracem slucaju taman toliko koliko traje sama write operacija (ako nije serializable izolacija), to je fakat. Ali postoji drasticna razlika izmedju X locka koji je deo server side SQL transakcije i manuelnog X locka koji se drzi u serializable izolaciji na aplikativnom nivou. Dobro skalabilno programiranje se bazirana na minimizaciji vremena koje procesi provode u WAIT state-u a jedan od efkiasnih nacina je maksimalna optimizacija trajanja X lockova.

Jedina situacija u kojoj je jedino i iskljucivo moguce koristiti produzeni pesimistic lock je two-way distributed transakcija koja izlazi van scope-a sql transakcije. Tu moras da drzis pesimistic lock nad objektom u SQL transakciji dok ne kompletiras sve ostale korake DT-e i tu nema pomoci (sem mozda reorganizovanje samog poslovnog procesa i osiguravanja atomicnosti kroz neke druge mehanizame, npr odlozena operacija kroz Queue)

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 14:15 - pre 197 meseci}

Citat:

mmix: Ok, ja sam izneo konkretan razlog zasto je drzanje pesimistickog locka lose (doduse u drugoj temi, ali sad sam tu poruku prebacio ovamo gde joj je mesto, pa procitaj ponovo gore). Koje je tvoje objasnjenje zasto je optimistic lock los i losiji od dugotrajnog drzanja X locka?

Prvo da razjasnimo nešto. Ako sam dobro shvatio tvoj termin X lock = pesimističko zaključavanje. Nastavljamo dalje.
Tvrdiš da sam protivnik optimističnog zaključavanja i da zagovaram dugotrajni pesimistično zaključavanje. Na osnovu čega si to zaključio? Da ponovim tema glasi:Pesimisticko zakljucavanje - razlozi za i protiv. Drugim rečima kada je neophodno i na aplikativnom nivou koristiti pesimističko zaključavanje i kako podatke što kraće vreme držati zaključane. To je suština pitanja postavljenog u temi.

Citat:

Nisu samo klijenti koji aktivno azuriraju bazu smetnja, zapravo oni su retko kad smetnja jedni drugima jer obicno manjaju razlicite redove u tabelama ...
...
Ono sto je mnogo veci problem su svi ostali korisnici sistema koji imaju potrebu da cesto citaju te tabele i redove, a citanje (SELECT) nije potpuno pasivna operacija ...

Literatura koju sam ja do sada čitao tvrdi da je zaključavanje mehanizam koji štiti konzistentnost baze prilikom istovremenog menjanja podataka u višekorisničkom okruženju. Do sada nisam naišao na podatak da se i kod pregleda podataka koristi zaključavanje (uz uslov je da nema ažuriranja).
Molim te, budi ljubazan, da mi daš izvor odakle potiču tvrdnje iznete u prethodnom citatu. Možda ima još zanimljivih i poučnih tekstova.

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 15:29 - pre 197 meseci}

Citat:

mkaras: Prvo da razjasnimo nešto. Ako sam dobro shvatio tvoj termin X lock = pesimističko zaključavanje.

Ne, nisi dobro shvatio i ne nije moj termin, X lock (od eXlusive) je lock pri kojem odredjeni proces ima nedeljeno pravo nad odredjenim objektom (za razliku od npr S (Shared) lock-a koji kao sto mu ime kaze moze biti dodeljen istovremeno). Ultimativno svi update/insert pesimisticki lockovi zavrsavaju sa GRANT-om na X locku, ali X lock sam po sebi nije pesimisticko zakljucavanje. Pesimisticko zakljucavanje je svako zakljucavanje kojim se moze izazvati blokiranje drugog procesa u izvrsenju tj svaki lock koji moze oterati drugi proces u WAIT state. To izmedju ostalog ukljucuje i blokiranje update operacija drzanjem S lockova.

Na MSSQL-u, ako izdas sp_lock komandu u query analyzer-u/query editoru dobices spisak svih trenutno aktivnih lockova i statusa procesa, npr:

Code:
60 16 0            0    DB                   S   GRANT
60 16 229575856    0    TAB                  IS  GRANT
60 16 229575856    0    PAG    1:203         IS  GRANT
60 16 229575856    0    RID    1:203:0       S   WAIT

61 16 0            0    DB                   S   GRANT
61 16 229575856    0    TAB                  IX  GRANT
61 16 229575856    0    PAG    1:203         IX  GRANT
61 16 229575856    0    RID    1:203:0       X   GRANT

Proces 60 ceka na shared lock za red (RID) na kojem proces 61 drzi X lock. Skripte koje su ovo 'izazvale' su

61: begin transaction; update TT2 set s1 = 12 where s1=123.0;
60: select * from TT2 where s1=123.0;

i ovo je najjednostavniji primer sta pesimistcki lock na aplikativnom nivou radi sa skalabilnoscu. Dok god P61 ne uradi commit ili rollback P60 (i svi ostali koji imaju wait na tom objektu) ce biti blokiran.

Citat:

mkaras: Literatura koju sam ja do sada čitao tvrdi da je zaključavanje mehanizam koji štiti konzistentnost baze prilikom istovremenog menjanja podataka u višekorisničkom okruženju. Do sada nisam naišao na podatak da se i kod pregleda podataka koristi zaključavanje (uz uslov je da nema ažuriranja).
Molim te, budi ljubazan, da mi daš izvor odakle potiču tvrdnje iznete u prethodnom citatu. Možda ima još zanimljivih i poučnih tekstova.

Evo ti izlaz sa sp_lock-a gore, ocigledno je da postoji S lock pri select-u, ako mi ne verujes a ti probaj sam ovde dve skriptice pa vidi. QED. Problem je sto ti citas populisticku literaturu za SQL admine, a vecina SQL materijala jeste takva. Ja koliko znam ne postoji knjiga (a mozda i postoji samo ja ne znam za nju) koja bi ti to objasnila u detalje niti je to interesantno generalnoj populaciji jer samo SQL server ima skoro 20 razlicitih lock kategorija (S, U i X su samo najcesci, nisu jedini). To bi bilo poglavlje koje bi svi preskocili.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 21:26 - pre 197 meseci}

Citat:

mmix: ...
Ja koliko znam ne postoji knjiga (a mozda i postoji samo ja ne znam za nju) koja bi ti to objasnila u detalje niti je to interesantno generalnoj populaciji jer samo SQL server ima skoro 20 razlicitih lock kategorija (S, U i X su samo najcesci, nisu jedini). To bi bilo poglavlje koje bi svi preskocili.

Ne bih baš rekao. Naveo sam već jednu knjigu u kojoj je zaključavanje jako lepo objašnjeno a ima i knjiga Professional SQL Server 2000 Programming, pisac je Robert Vieira. Kod nas se može naći u izdanju CET-a.
Termin populistička literatura za SQL admine mi ni je potpuno jasan pa ga malo pojasni.
Neki autori nemaju baš lepo mišljenje o sp_lock proceduri. Robert Vieira je čak dao predlog proccedure koja mnogo korektnije obavlja posao. Sledi u nastavku:

Code:
USE master
GO

CREATE PROC sp_DBLocks
    @DBNameIn     sysname      = NULL,
    @ObjName     sysname      = NULL

WITH RECOMPILE
AS
/* Sproc Authored and Copyright By Robert M. Vieira, MCDBA 1999, 2000    */
/* This sproc is made availabe for public, non-commercial use              */
/* All other rights reserved                        */

-- Declare holding variable for dynamic query
DECLARE @cmd         varchar(1000)
DECLARE @DBName        sysname

-- If no database was supplied, then assume current database
SELECT @DBName = ISNULL(@DBNameIn, DB_NAME())

-- Verify that the supplied database exists
IF NOT EXISTS (SELECT * FROM master.dbo.sysdatabases
    WHERE Name = @DBName)
    BEGIN
        RAISERROR(15010,1,1,@DBname) WITH SETERROR
        RETURN 15010
    END



-- Build it (and they will come...)
SELECT @cmd =
'    SELECT     convert (smallint, req_spid) As spid,
        rsc_dbid As dbid,
        rsc_objid As ObjId,
        so.Name As ObjectName,
        rsc_indid As IndId,
        substring (v.name, 1, 4) As Type,
        substring (rsc_text, 1, 16) as Resource,
        substring (u.name, 1, 8) As Mode,
        substring (x.name, 1, 5) As Status

    FROM     master.dbo.syslockinfo sli
    JOIN    master.dbo.spt_values v
      ON        sli.rsc_type = v.number
     AND        v.type = ''LR''
    JOIN    master.dbo.spt_values x
      ON        sli.req_status = x.number
     AND        x.type = ''LS''
    JOIN    master.dbo.spt_values u
      ON        sli.req_mode + 1 = u.number
     AND        u.type = ''L''
    JOIN    master.dbo.sysdatabases sd
      ON        sli.rsc_dbid = sd.dbid
    JOIN    ' + @DBName + '.dbo.sysobjects so
      ON        sli.rsc_objid = so.id
    WHERE    sd.name = ''' + @DBName + ''''

-- If an object name was supplied, add the piece that will restrict to supplied name
-- Otherwise, leave it off to get all objects in the specified DB
IF NOT (@ObjName IS NULL)
    SELECT @CMD = @CMD +      ' AND    so.Name = ''' + @ObjName + ''''

-- I'm Ordering by spid, but by Object Name seems a likely candidate if one wasn't supplied
SELECT @CMD = @CMD + '    ORDER BY    spid'

-- Create a little header
IF @ObjName IS NULL
    PRINT 'Resource Locks for Database ' + @DBName
ELSE
    PRINT 'Resource Locks for Database ' + @DBName + ', Resource ' + @ObjName

-- We've built it, time for them to come....
EXEC (@cmd)

-- Hopefully, this is zero
RETURN @@ERROR

GO

/* I haven't figured out why this has to be in here, but it doesn't seem to **
** work correctly until it is executed once with the mater database current */
PRINT 'What follows is a primer run of the sproc'
EXEC sp_DBLocks

_{[Ovu poruku je menjao mkaras dana 12.02.2009. u 22:37 GMT+1]}

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 22:12 - pre 197 meseci}

Pa ne bih rekao da su te knjige bajne, ti si ih izgleda procitao cim ih citiras a nisi znao za S lock niti si znao kako zaista radi lockovanje, samim tim knjiga je nekompletna i lockovanje nije dobro objasnjeno (ili to ili nasumice citiras iz knjiga koje nisi procitao) odatle i konstatacija da je populisticko. Zapravo statisticki mogu slobodno da kazem da je objasnjeno u onoj meri koliko je mcdba ljudima neophodno za njihov posao, ni manje ni vise i da budem siguran da nisam pogresio; mozda nisam tu specificnu knjigu video ali sam ih se dovoljno nagledao da znam da lice jedna na drugu i da su uvek high-level.

I sta ti mislis sta sp_lock radi? Vraca master.dbo.syslockinfo informacije u kondenzovanom prikazu. Sve sto ova procedura radi je joinovanje na tabele u kojima su objekti deklarisani po imenima i daje deskriptivniji izlaz. To sto je Vieria otkrio rupu na saksiji ne znaci da je to uradio prvi, proguglaj za Google: "sp_lock2" proceduru koja se vrti jos od SQL 7-e (KB: 255596), a ima jos bar nekoliko derivata iste pored Vierine. Izlaz iz sp_lock sam okacio da bi ti pokazao lockovanje i wait blokadu i da bi izlaz mogao svako da reprodukuje bez da ima specijalizovane procedure.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{12.02.2009. u 23:37 - pre 197 meseci}

Citat:

mmix: Pa ne bih rekao da su te knjige bajne, ti si ih izgleda procitao cim ih citiras a nisi znao za S lock niti si znao kako zaista radi lockovanje, samim tim knjiga je nekompletna i lockovanje nije dobro objasnjeno (ili to ili nasumice citiras iz knjiga koje nisi procitao) odatle i konstatacija da je populisticko. Zapravo statisticki mogu slobodno da kazem da je objasnjeno u onoj meri koliko je mcdba ljudima neophodno za njihov posao, ni manje ni vise i da budem siguran da nisam pogresio; mozda nisam tu specificnu knjigu video ali sam ih se dovoljno nagledao da znam da lice jedna na drugu i da su uvek high-level.

I sta ti mislis sta sp_lock radi? Vraca master.dbo.syslockinfo informacije u kondenzovanom prikazu. Sve sto ova procedura radi je joinovanje na tabele u kojima su objekti deklarisani po imenima i daje deskriptivniji izlaz. To sto je Vieria otkrio rupu na saksiji ne znaci da je to uradio prvi, proguglaj za Google: "sp_lock2" proceduru koja se vrti jos od SQL 7-e (KB: 255596), a ima jos bar nekoliko derivata iste pored Vierine. Izlaz iz sp_lock sam okacio da bi ti pokazao lockovanje i wait blokadu i da bi izlaz mogao svako da reprodukuje bez da ima specijalizovane procedure.

O knjigama pričaj kada ih budeš pročitao. O S zaključavanju nismo diskutovali već samo o X tipu pa si rekao da sva pesimistička zaključavanja postanu zaključavanja tipa X.
A što se tiče deljivog zaključavanja (S) koristi se samo kada se podaci čitaju a ne menjaju se. Drugim rečima obaveštava sistem zaključavanja da se nešto radi sa podacima. Ali ni na koji način ne ograničava drugim procesima da pristupe podacima. Samim tim i nije baš neko zaključavanje.

Blokadu si imao zato što si koristio transakciju koja menja podatke i normalno je da dok ne završi posao ne dozvoli pristup podacima koje obrađuje. I to je sasvim normalna situacija jer kada bi izvršio upit dobio bi rezultate koji već u sledečem trenuku ne bi bili istiniti.
I drago mi je da smo se složili da je pesimističko zključavanje isto što i ekskluzivno (X). I jedno i drugo kad dohvati podatke ne dopušta drugim procesima da im pristupe.

_{[Ovu poruku je menjao mkaras dana 13.02.2009. u 11:03 GMT+1]}

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 11:46 - pre 197 meseci}

Ko se slozio? Nemoj izmisljati stvari i tvrditi nesto sto ja nisam rekao, a nemoj se ni hvaliti onim sto su drugi rekli kao da si oduvek znao jer par poruka gore nisi ni znao da SELECT izaziva S lockove. Dozvoli mi da citiram sebe posto ocigledno ne vidis ili ne citas ono sto ti se pise:

Citat:

Pesimisticko zakljucavanje je svako zakljucavanje kojim se moze izazvati blokiranje drugog procesa u izvrsenju tj svaki lock koji moze oterati drugi proces u WAIT state. To izmedju ostalog ukljucuje i blokiranje update operacija drzanjem S lockova.

Dakle SELECT sa svojim S lockom je takodje pesimisticko zakljucavanje u serializable izolaciji. Hoces primer? Evo najprostiji:

57: select * from TT2
59: update TT2 set s1 = 12 where s1=123; izvrsena tokom 57

Code:

57 16 229575856 0 TAB S GRANT
59 16 229575856 0 TAB IX WAIT

Dakle, update ceka da se oslobodi S lock, dakle SELECT je izazvao pesimisticko zakljucavanje. Dakle, nismo se slozili nego ti i dalje ne citas sta je napisano i ni ne pokusavas da naucis nesto od ljudi koji bolje znaju od tebe, samo guras svoju pricu i slazes netacne konstrukcije iskrivljujuci ono sto sam ti napisao. Namerno nisam isao dalje od serializable izolacije da bi video dal ces me demantovati kroz stepene izolacije, ali tvoje neznanje je suvise veliko. Vidis ovo sto kategoricki tvrdis zavisi od stepena izolacije:

Citat:

Blokadu si imao zato što si koristio transakciju koja menja podatke i normalno je da dok ne završi posao ne dozvoli pristup podacima koje obrađuje. I to je sasvim normalna situacija jer kada bi izvršio upit dobio bi rezultate koji već u sledečem trenuku ne bi bili istiniti.

Taj stepen izolacije koji to dozvoljava i te kako postoji i zove se READ UNCOMMITTED. Hoces primer i za to? U stvari ne, zavrsio sam sa pokusajima da tebi objasnim nesto. Ako je i zarad opsteg doprinosa kvalitetnijem softveru, mnogo je. Sa mog stanovista oni koji citaju ovu temu a imali su dilema oko toga kako pesimistic lock na aplikativnom nivou ometa skalabilnost sad imaju konkretne informacije o tome. Ako nekom treba jos nesto nek trazi slobodno, dodacu, a sto se tebe tice, zavrsili smo.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

Fedya
Fedor Hajdu
Solution Architect
Emaratech
Dubai, UAE

Član broj: 28246
Poruke: 790
82.117.202.*

Jabber: fedya@elitesecurity.org
Sajt: devtechgroup.com

+34 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 13:10 - pre 197 meseci}

Pisci pisu knjige da bi se one prodale, i pise se za 'siroke narodne mase' da bi sto vise ljudi imalo bar neke koristi.

Ako ti covek da kod koji jasno pokazuje nesto (poteraj pa vidi) tvoj argumet tipa 'ja to nisam procitao ni u jednoj knjizi i to samim tim ne moze biit istina' jednostavno ne pije vodu.

A sto se same rasprave tice, SELECT izaziva pesimisticko zakljucavanje osim ako mu se drugacije ne naglasi. Znaci: select * from TT2 WITH (NOLOCK) ne izaziva lockove.

takodje ako bi izvrsio taj upit (sa with nolock) tvoja izjava

Citat:

Blokadu si imao zato što si koristio transakciju koja menja podatke i normalno je da dok ne završi posao ne dozvoli pristup podacima koje obrađuje. I to je sasvim normalna situacija jer kada bi izvršio upit dobio bi rezultate koji već u sledečem trenuku ne bi bili istiniti.

bi opet bila pogresna, posto bi dobio 'neistinite podatke' kako ih ti nazivas. Takodje mozes spustiti isolation level na read uncommitted i dobices isti rezultat.

A ako bi isli na suprotnu stranu (podizali nivo izolacije) ti bi jos manje bio u pravu - a izbaciti isolation level iz rasprave o zakljucavanju bi bilo pomalo smesno

Edit: Odlutale misli na posao
_{[Ovu poruku je menjao Fedya dana 13.02.2009. u 14:25 GMT+1]}

_{[Ovu poruku je menjao Fedya dana 13.02.2009. u 14:26 GMT+1]}

Every hamster has his day.

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 15:39 - pre 197 meseci}

Nisu sve knjige za široke narodne mase. Neke od knjiga služe i za ozbiljno upoznavanje sa problematikom. mmix je autore kao što su: Mike Gunderloy, Joseph L. Jorden i Robert Vieira proglasio piscima beletristike. Jedan je mmix a svi ostali su daleko, daleko iza. Ovo je približno tekst poruke koju je vrli moderator obrisao.
Ali da ne bude da ga samo kritikujem, moram i da ga pohvalim. Veoma lepo je primetio da su zamene za proceduru sp_lock nastale još i u doba MS SQL servera 7. Ipak mora da postoji ozbiljan razlog zašto se to radi. Nisam ubeđen da je izlaz procedure sp_lock uvek primenljiv. Nekada su podaci koji se dobiju lažni. Naime, pokušaj da izvršiš neki upit koji čita podatke i, u isto vreme dok se upit izvršava, pokreni sp_lock. Dobićeš prilične gluposti kao odgovor. Jedna od njih je i da je tabela nad kojom vršiš upit ekskluzivno zaključana. Dokaz da nije tako je taj što u isto vreme možeš da izvršiš više istovremenih upita koji samo čitaju podatke.

Odgovor na temu

Fedya
Fedor Hajdu
Solution Architect
Emaratech
Dubai, UAE

Član broj: 28246
Poruke: 790
82.117.202.*

Jabber: fedya@elitesecurity.org
Sajt: devtechgroup.com

+34 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 15:57 - pre 197 meseci}

Code:

54 1 1115151018 0 TAB IS GRANT

Znaci tu postoji Shared lock (IS u pretposlednjoj koloni).

Podaci u tabeli su zakljucani, ne mogu se menjati, ali ako se ubaci jos jedan select on koristi isti lock (posto je shared). Znaci ako izvrsis 10 select-a u isto vreme i jedan update, select-i ce svi vratiti isti set podataka (posto dele isti lock - taj lock ce se postaviti kada prvi upit zapocne izvrsavanje i osloboditi kada poslednji select zavrsi - ali to je i dalje isti lock). Ali ce update morati da saceka da svi zavrse.

Every hamster has his day.

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 16:39 - pre 197 meseci}

Pazi, logika je vrlo, vrlo jednostavna, da prostija ne moze biti. Ti ne znas sta je i kako radi lockovanje i concurrency mehanizmi na SQL Serveru. To je fakat i to si pokazao svojim postovima. A tvrdis da si procitao te knjige od Mike Gunderloy, Joseph L. Jorden i Robert Vieira-e. Ajd da ti poverujemo. Ono sto logicki preostaje su dve opcije:

1. Knjige su populisticke i lose objasnjene (u sta sam skloniji da poverujem), beletristika kako ti kazes ili
2. ti nisi u stanju da naucis iz tih knjiga.

Ne znam, ja da sam na tvom mesto pre bih se odlucio za prvi odgovor, zvuci manje lose. Kao sto ti je i Fedya rekao, te knjige se pisu za siroku populaciju koja ne zna i ne zeli da zna kako dubinski radi lockovanje, to ne znaci da autori ne znaju i da sam ja pametniji od njih, to samo znaci da ako to znanje i imaju isto nisu preneli u knjige. Jer da jesu ti bi to naucio, zar ne?

Nemoj samo da me hvalis, molim te. Kad pricamo o aroganciji, ta tvoja tvrdnja o sp_lock-u i njegovoj laznosti je daleko sjajnija. sp_lock je zapravo jedini metod za prikaz aktivnih lockova koji je stabilan i uvek tacan. Sve ostale varijante koje se baziraju na syslockinfo tabeli nisu stabilne i rade za verziju SQL servera za koju su napisane. Zasto? Zato sto MS ne garantuje komaptibilnost master baze uopste. Ne samo da se sema master baze menja izmedju verzija servera nego se menja i izmedju service pack-ova. MS moze sasvim komotno da preimenuje syslockinfo u newsyslockinfo ili da podeli lockove na 20 razlicitih tabela (za svaki locktype po jednu) i da pokvari sve 3rd party skripte koje koriste tu tabelu, medjutim sp_lock ce i dalje raditi jer ga oni odrzavaju. Ili ja sad treba da napisem: "Jedan je mkaras, a svi ostali ukljucujuci MS SQL Team su daleko iza..."

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mkaras
Marko Karas
Beograd

Član broj: 66087
Poruke: 427

+19 Profil

Re: Pesimisticko zakljucavanje - razlozi za i protiv

^{13.02.2009. u 22:50 - pre 197 meseci}

Citat:

Code:

54111151510180 TAB IS GRANT

Znaci tu postoji Shared lock (IS u pretposlednjoj koloni).

Podaci u tabeli su zakljucani, ne mogu se menjati, ali ako se ubaci jos jedan select on koristi isti lock (posto je shared). Znaci ako izvrsis 10 select-a u isto vreme i jedan update, select-i ce svi vratiti isti set podataka (posto dele isti lock - taj lock ce se postaviti kada prvi upit zapocne izvrsavanje i osloboditi kada poslednji select zavrsi - ali to je i dalje isti lock). Ali ce update morati da saceka da svi zavrse.

IS zaključavanje je deljeno zaključavanje u najavi i nema neko obavezujuće dejstvo, više je informativnog karaktera. Nad resursom nad kojim postoji IS zaključavanje u svakom momentu mogu da se odobre i primene sledeća zaključavanja: IS, S, U, IX ili SIX .

Odgovor na temu

[es] :: MS SQL :: Pesimisticko zakljucavanje - razlozi za i protiv

[ Pregleda: 3916 | Odgovora: 15 ] > FB > Twit

Srodne teme

18.09.2007. pasword maska za zakljucavanje shift keya
22.09.2007. Database (mySQL) record lock ?
31.01.2008. Australian Open & Serbian Storm
19.08.2012. Daljinsko zakljucavanje
14.05.2009. zakljucavanje usb stika sifrom
28.08.2008. Reno laguna 96 daljinsko zakljucavanje
29.09.2008. Rucna vektorizacija protiv kompjuterske!
04.12.2008. nokia 6120 zakljucavanje poruka

Navigacija

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