för det förstöra instansmetoden. Den semantiska skillnaden är subtil, men blir tydlig när before_destroy callbacks specificeras eller beroende associationer skapas, det vill säga underordnade objekt som automatiskt måste förstöras tillsammans med föräldern.

Låsa Databas

Termen låsning hänvisar till en teknik som förhindrar flera samtidiga användare från att uppdatera samma poster. När tabellrader laddas in i en modell tillämpar ActiveRecord inte låsning alls som standard. Om i några Rails ansökan Endast en användare kan uppdatera data när som helst, så det finns ingen anledning att oroa sig för lås.

Om det finns en chans att läsning och uppdatering av data kan utföras samtidigt av flera användare, måste du vara försiktig

konkurrenskraft. Fråga dig själv, vilka kollisioner eller tävlingsförhållanden kan inträffa om två användare försöker uppdatera modellen samtidigt?

Det finns flera metoder för att redovisa samtidighet i databasapplikationer. ActiveRecord har inbyggt stöd för två av dem: optimistisk Och pessimistisk blockering. Det finns andra

Andra alternativ, som att låsa hela bord. Varje tillvägagångssätt har många styrkor och svagheter, därför, för den mest tillförlitliga driften av applikationen, är det vettigt att kombinera dem.

Optimistiskt lås

En optimistisk blockeringsstrategi är att upptäcka och lösa konflikter när de uppstår. Det rekommenderas vanligtvis för användning i fall där kollisioner inträffar sällan. Optimistisk låsning låser inte databasposter alls, så namnet är bara förvirrande.

Optimistisk låsning är en ganska vanlig strategi eftersom många applikationer är designade så att alla användare bara ändrar data som begreppsmässigt är deras ensamma. Därför är påståenden om att uppdatera samma post osannolikt. Tanken bakom optimistisk blockering är att eftersom kollisioner är sällsynta behöver de bara hanteras om de faktiskt inträffar.

Om du kontrollerar databasschemat är det ganska enkelt att implementera optimistisk låsning. Det räcker att lägga till en heltalskolumn i tabellen med namnet lock_version och ett standardvärde på 0:

Databaslås
	AddLockVersionToTimesheets< ActiveRecord::Migration
add_column:timesheets, :lock_version, :integer, :default => 0

remove_column:timesheets, :lock_version end

Själva närvaron av en sådan kolumn ändrar beteendet hos ActiveRecord. Om någon post läses in i två instanser av modellen och sparas med olika betydelser attribut, kommer uppdateringen av den första instansen att slutföras framgångsrikt, och vid uppdatering av den andra kommer användningen av

Inklusive ActiveRecord::StaleObjectError.

För att illustrera optimistisk låsning, låt oss skriva ett enkelt fristående test:

klass Tidrapporttest< Test::Unit::TestCase

matcher: tidrapporter, :användare

def test_optimistic_locking_behavior first_instance = Timesheet.find(1) second_instance = Timesheet.find(1)

first_instance.approver = användare(:approver) second_instance.approver = användare(:approver2)

hävda first_instance.save, "Den första instansen har sparats"

assert_raises ActiveRecord::StaleObjectError gör second_instance.save

Testet godkänns eftersom vi förväntar oss ett ActiveRecord::StaleObjectError-undantag när vi anropar save i den andra instansen. Anteckna det

att sparmetoden (utan utropstecken) returnerar false och höjer inte undantag om räddningen misslyckas pga datakontrollfel. Andra problem, till exempel ett skrivlås, kan resultera i ett undantag. Om du vill att kolumnen som innehåller versionsnumret ska kallas något annat än lock_version , ändra denna inställning med metoden set_locking_column. För att göra denna förändring global, lägg till följande rad i filen environment.rb:

ActiveRecord::Base.set_locking_column "alternate_lock_version"

Liksom andra ActiveRecord-inställningar kan denna ställas in på modellnivå genom att inkludera följande deklaration i modellklassen:

klass Tidrapport< ActiveRecord::Base set_locking_column "alternate_lock_version"

Hantera StaleObjectError Exception

När du väl lägger till optimistisk låsning vill du absolut inte sluta där, för annars kommer användaren som hamnar i den förlorande delen av kollisionsupplösningen helt enkelt att se ett felmeddelande på skärmen. Vi måste försöka hantera StaleObjectError-undantaget med minsta möjliga förluster.

Om informationen som uppdateras är mycket viktig, kanske du vill lägga tid på att bygga ett användarvänligt system som på något sätt lagrar de ändringar som användaren försökte göra. Om uppgifterna är lätta att ange igen, informera åtminstone användaren om att uppdateringen inte ägde rum. Nedan är kontrollkoden som implementerar detta tillvägagångssätt:

def uppdatering börjar

@timesheet = Timesheet.find(params[:id]) @timesheet.update_attributes(params[:timesheet])

# redirect rescue ActiveRecord::StaleObjectError någonstans

flash[:error] = "Rapportkortet ändrades medan du redigerade det." redirect_to:action => "redigera", :id => @tidrapport

Optimistisk låsning har en rad fördelar. Det kräver inga speciella DBMS-mekanismer, och det är relativt enkelt att implementera. Som du kan se från exemplet krävdes väldigt lite kod för att hantera Stale ObjectError-undantaget.

Nackdelarna beror främst på att uppdateringsoperationerna tar lite längre tid, eftersom låsversionen måste kontrolleras. Dessutom kan användare vara missnöjda eftersom de lär sig om felet först efter att ha skickat data, vilket skulle vara extremt oönskat att förlora.

Pessimistisk lås

För pessimistisk blockering särskilt stöd krävs från DBMS (de vanligaste DBMS har det dock). Under uppdateringsoperationen är vissa rader i tabellerna låsta. Detta förhindrar andra användare från att läsa de poster som kommer att uppdateras, vilket förhindrar möjligheten att arbeta med föråldrad data.

Blockering och avblockering

Om du föredrar att använda några andra verktyg för att skapa databassäkerhetskopior eller bara göra en vanlig kopia av databasen som en säkerhetskopia, så kommer nbackups lås/upplåsningsläge in i bilden. "Blockera" in I detta fall betyder att huvuddatabasfilen är tillfälligt fryst, inte oförmågan att göra ändringar i databasen. Liksom i säkerhetskopieringsläge, är ändringar förpliktade till en temporär deltafil; när den är upplåst slås deltafilen samman med huvuddatabasfilen.

Som en påminnelse: nbackup.exe finns i bin-undermappen i mappen där Firebird DBMS är installerat. Typiska platser är till exempel C:\Program Files\Firebird\Firebird_2_0\bin (Windows) eller /opt/firebird/bin (Linux). Verktyget har inte GUI; Du startar den från kommandorad(eller från kommandofil, eller från en annan applikation).

Databaslåsning och självsäkerhetskopiering

Ett typiskt scenario är följande:

Lås en databas med en parameter -L(Låsa):

nbackup[-U <пользователь> -P <пароль> ] -L <база_данных>

1. Nu kan du skapa en säkerhetskopia, komprimera databasfilen (och mycket mer du kan göra med innehållet i databasfilen) med dina favoritprogram. Att bara kopiera filen är också acceptabelt.

   Lås upp databas med parameter -N(låsa upp):

   nbackup[-U <пользователь> -P <пароль> ] -N <база_данных>

Det sista kommandot kommer också att slå samman deltafilen, där alla ändringar av (meta)data under låsningen skrevs, med huvuddatabasfilen.

Den skapade säkerhetskopian kommer att innehålla data som var aktuell vid den tidpunkt då blockeringen började; dessa data beror inte på blockeringens varaktighet, liksom på den tid som har gått från början av blockeringen till början av säkerhetskopieringen.

Uppmärksamhet

Det som gäller för säkerhetskopiering/återställning gäller även för låsning/upplåsning: använd inte lås/upplåsning på flerfilsdatabaser. Tills situationen förändras, håll nbackup borta från databaser med flera filer!

Återställer från en säkerhetskopia som gjorts efter att ha kört "nbackup -L"

En kopia av en låst databas är också låst, så du kan inte bara använda kopian som en arbetsdatabas. Om din ursprungliga databas är skadad eller förlorad och du behöver återställa databasen från en kopia som du själv har gjort, gör så här:

1. Packa upp/kopiera/återställ databasfilen med hjälp av de verktyg du använder.

   Lås upp databasen nu, men Inte med parameter -N, och med parametern -F(Fixa till):

   nbackup -F <база_данных>

Varför finns det två kommandoradsalternativ, -N Och -F?

• När du använder parametern -N bestämmer först om det har skett några ändringar sedan databasen låstes (efter att ha använt -L) och den temporära deltafilen och huvuddatabasfilen slås samman. Därefter sätts databasen i normalt läs/skrivläge och den temporära filen raderas.

  När du använder parametern -Fändrar bara statusflaggan för en självåterställd databas till det "normala" värdet.

Så du använder:

parameter -N efter skapande säkerhetskopia på egen hand (för att returnera statusflaggan efter att tidigare blockerat en fil med parametern -L);

parameter -F efter oberoende återhämtning från en sådan backup.

Kommentar

Det gick inte så bra att den sista parametern -F uppkallad efter ordet Fixup: dess syfte är inte att fixa någonting, utan bara låsa upp databas. Parameter -N(Lås upp, lås upp), å andra sidan, låser inte bara upp databasen, utan gör även vissa ändringar i den (implementerar ändringarna som gjorts i databasen). Vi kommer dock att få jobba med det vi har.

Idag kommer vi att prata om blockering både på 1C 8.3- och 8.2-nivån och på DBMS-nivån. Datalåsning - nödvändigt element alla system där antalet användare är fler än en.

Nedan kommer jag att beskriva hur blockering fungerar och vilka typer det är.

Ett lås är information om att en systemresurs har tagits i beslag av en annan användare. Det finns en åsikt att blockering är ett misstag. Nej, låsning är en oundviklig åtgärd i ett fleranvändarsystem för att dela resurser.

Endast redundanta ("onödiga") lås kan orsaka skada på systemet. Du måste lära dig hur man eliminerar sådana blockeringar de kan leda till suboptimal systemdrift.

Lås i 1C är konventionellt uppdelade i objekt och transaktioner.

Objektiva är i sin tur optimistiska och pessimistiska. Och transaktionsrelaterade kan delas in i hanterade och automatiska.

Objektlås 1C

Denna typ av låsning är helt implementerad på 1C-plattformsnivå och påverkar inte DBMS på något sätt.

Få 267 videolektioner på 1C gratis:

Pessimistiska lås

Denna blockering utlöses när en användare har ändrat något i katalogformuläret, och den andra försöker ändra ett objekt i formuläret på samma sätt.

Optimistiska lås

Det här låset jämför versioner av ett objekt: om två användare öppnade ett formulär och en av dem ändrade och skrev ner objektet, då när du skriver till det andra kommer systemet att ge ett felmeddelande om att versionerna av objekten är olika.

Transaktionslås 1C

1C transaktionslåsmekanismen är mycket mer intressant och mer funktionell än objektlåsmekanismen. Denna mekanism involverar aktivt låsning på DBMS-nivå.

Felaktig användning av transaktionslås kan leda till följande problem:

• problem med förlorad förändring;
• smutsigt läsproblem;
• läsningens unika;
• läsa fantomer.

Dessa problem diskuterades i detalj i artikeln om.

Automatiska transaktionslås 1C och DBMS

I automatiskt läge DBMS är helt ansvarig för låsning. Utvecklaren i detta fall är absolut inte involverad i processen. Detta gör arbetet för en 1C-programmerare enklare, men att skapa informationssystem För stor kvantitet användare per automatisk blockering oönskat (särskilt för PostgreSQL DBMS, Oracle BD - när du ändrar data låser de tabellen helt).

För olika DBMS:er används olika grader av isolering i automatiskt läge:

• SERIALISERBAR för hela bordet – filläge 1C, Oracle;
• SERIALISERBAR på poster – MS SQL, IBM DB2 när man arbetar med icke-objektiva enheter;
• REPETERBAR LÄSNING på poster – MS SQL, IBM DB2 vid arbete med objektentiteter.

Hanterat läge för transaktionslås 1C och DBMS

Utvecklaren av applikationslösningen på 1C-nivå tar fullt ansvar. I det här fallet installerar DBMS tillräckligt hög nivå isolering för transaktioner - READ COMMITED (SERIALISERBAR för en fil DBMS).

När du utför någon operation med databasen analyserar 1C-låshanteraren möjligheten att blockera (beslagta) en resurs. Lås för samma användare är alltid kompatibla.

Två lås är INTE kompatibla om: de är installerade av olika användare, de är av inkompatibla typer (exklusiva/delade) och de är installerade på samma resurs.

Fysisk implementering av lås i ett DBMS

Fysiskt sett är lås en tabell som finns i databasen som kallas master. Själva låsbordet heter syslockinfo.

Tabellen har normalt fyra fält:

1. Blockerar sessions-ID SPID;
2. exakt vad som blockeras av RES ID;
3. låstyp - S,U eller X LÄGE(i själva verket finns det 22 typer i MS SQL, men endast tre används tillsammans med 1C);
4. blockerande tillstånd - kan ta ett värde BEVILJA(installerad) och VÄNTA(väntar på hans tur).

När man arbetar med objektdata (kataloger, dokument, kontoplaner etc.) tillhandahåller 1C:Enterprise-systemet två typer av objektlås: pessimistiska och optimistiska. De låter dig utföra holistiska ändringar av objekt medan flera användare arbetar samtidigt.

Objekt pessimistisk låsning

Ett pessimistiskt objektlås är utformat för att förhindra ändringar av ett objekts data tills låset släpps. Systemet (med hjälp av lämpliga objektformstillägg) sätter automatiskt ett pessimistiskt lås i det ögonblick då användaren försöker ändra objektdata. Om en annan användare sedan försöker redigera samma objekt, till exempel, kommer de att få ett meddelande som indikerar att objektet inte kunde låsas. När formuläret stängs av användaren, denna blockering kommer att tas bort.

Låt oss titta på ett exempel.
Låt oss gå in i utbildningsinformationsbasen under användaren "Vasiliev V.V.", öppna dokumentformuläret "Mottagning av varor 00000000001 daterad 06/01/2016" och gör ändringar i kommentarsfältet (Fig. 1.3).

Utan att spara dokumentet, låt oss gå in i informationsdatabasen under användaren "Ivanov I.I.", öppna samma dokument och försöka göra ändringar i någon av dokumentdetaljerna. Systemet tillåter inte att vi gör ändringar och kommer att visa ett felmeddelande (Fig. 1.4).

Av detta följer att pessimistisk låsning garanterar att användaren, efter att ha börjat ändra objektdata, kommer att kunna skriva dessa ändringar till informationsbasen.

Utvecklaren, med hjälp av det inbyggda språket, kan använda pessimistisk låsning. Med metoden "Lock()" ställs ett pessimistiskt objektlås in, och metoden "Unlock()" används för att ta bort det.

Låt oss titta på ett annat exempel. Under användaren "Vasiliev V.V." i avsnittet "Reglerings- och referensinformation" öppnar du katalogelementet "Warehouses" med namnet "Warehouse No. 1" och gör ändringar i namnet (Fig. 1.5).

Byt till fönstret utan att spara informationsbas, som lanserades under användaren "Ivanov V.V.", i avsnittet "Referensinformation" kommer vi att öppna behandlingen "Ta bort ett objekt". Låt oss välja som objekt som ska raderas, välj katalogelementet "Warehouses" med namnet "Warehouse No. 1" och klicka på "Delete object" (Fig. 1.6).

Som ett resultat kommer systemet att tillåta dig att radera detta element katalogen och systemet kommer inte att visa ett felmeddelande. Poängen är att en låsoperation inte hindrar en operation för att ändra eller ta bort ett objekt i databasen.

För att säkerställa att ett låst objekt inte kan ändras eller raderas är det nödvändigt att kontrollera om objektet är låst.

Det finns två sätt att kontrollera:

1. Metoden Locked() används för att kontrollera om ett databasobjekt är låst av den aktuella sessionen. Den här metoden ger inte möjlighet att kontrollera om ett objekt alls är blockerat.
2. För att kontrollera om ett databasobjekt är låst, används vanligtvis metoden "Lock()". Ett försök att låsa ett låst objekt orsakar ett undantag, som kan hanteras av konstruktionen "Try…..Exception…..EndTry".

Pessimistisk blockering i kontrollerade former

När du arbetar med hanterade formulär kanske metoderna "Lock()", "Unlock()" och "Locked()" inte är lämpliga på grund av den hanterade applikationens särdrag.

Poängen är att dessa metoder används för databasobjekt. Databasobjektet finns bara på servern. Det visar sig att utvecklaren måste göra ett serveranrop, skaffa ett databasobjekt genom att konvertera huvudformulärattributet med formulärmetoden "Form AttributesValue". Därefter anropas en av objektets metoder "Lock()", "Unlock()" eller "Locked()". Men den här metoden låsning kommer att vara värdelös om målet är att objektet ska låsas medan formuläret är öppet, eftersom det resulterande objektet kommer att leva till slutet av serveranropet.

För att arbeta med lås från ett hanterat formulär måste du använda följande metoder: "LockFormDataForEditing()" och "UnlockFormDataForEditing()". Dessa metoder används för att blockera eller låsa upp data i huvudformulärets detaljer.

Låt oss titta på ett exempel. I avsnittet "Reglerings- och referensinformation" öppnar vi alla delar av katalogen "Nomenklatur" under användaren "Vasiliev V.V.", gör ändringar i namnet och utan att spara under användaren "Ivanov I.I." Låt oss öppna samma katalogelement. När du försöker göra ändringar kommer systemet att visa ett felmeddelande.

Vidare i form av ett katalogelement under användaren "Vasiliev V.V." Låt oss klicka på knappen "Avblockera" (Fig. 1.7) och försök igen att göra ändringar i detta katalogelement under användaren "Ivanov I.I." I det här fallet kommer systemet att tillåta dig att göra ändringar och spela in katalogelementet.

För att inaktivera pessimistisk låsning i hanterade formulär, i huvudattributegenskapen, måste du rensa flaggan "Lagrad data". Denna flagga bestämmer om huvudattributdata kommer att blockeras under interaktiv redigering eller inte (Fig. 1.8).

Objekt optimistisk låsning

Ett optimistiskt lås är en kontroll som utförs innan ett objekt skrivs till databasen. Objektet har en egenskap "DataVersion", som tillsammans med objektet läses från databasen. Optimistisk låsning utför, före skrivning, en jämförelse av värdet på "DataVersion"-egenskapen för objektet som finns i random access minne med värdet för egenskapen "DataVersion" för ett objekt som finns i databasen. Om värdena för "DataVersion"-egenskapen för objekt är olika, förhindrar optimistisk låsning att objektet skrivs till databasen och visar ett felmeddelande.

Låt oss titta på ett exempel.

I avsnittet "Reglerings- och referensinformation" öppnar vi alla element i katalogen "Nomenklatur" under användaren "Vasiliev V.V.", sedan utan att stänga elementformuläret under användaren "Ivanov I.I." i avsnittet "Reglerings- och referensinformation" öppnar vi bearbetningen "Ändra objekt".

Under behandlingen väljer du samma objekt och klickar på knappen "Ändra objekt". Detta kommando kommer att lägga till "!!!" i slutet av namnet (Fig. 1.9).

Efter förändringen, låt oss försöka skriva öppet element nomenklaturkatalogen under användaren "Vasiliev V.V." Systemet kommer att utfärda en varning om att dessa objekt har ändrats eller tagits bort och kommer inte att tillåta inspelning detta objekt(Fig. 1.10).

För att inaktivera optimistisk låsning, innan du skriver ett objekt i RAM, måste du jämföra versionen med versionen av databasobjektet. Om dataversionerna är olika, hämtar vi objektet från databasen och överför ändringarna till det och skriver det sedan.

Även i vissa DBMS kan du ställa in ett tidsintervall tidut– överskridande av tidsgränsen. När ett sådant intervall anges misslyckas SQL-satsen och returnerar en felkod om den inte lyckas få det erforderliga låset inom den angivna tidsperioden.

Databasadministratören kan manuellt ställa in låstyper, nivåer och tider tidut beroende på applikationsprogrammet.

Låslägen för specifik tillämpning(program) kan också installeras programmatiskt med hjälp av lämpliga objektmetoder Rekorduppsättning VBA-språk. I det här fallet, i ett specifikt fall, kommer programinställningarna redan att gälla, och inte de allmänna fönsterinställningarna alternativ. Det här alternativet ger mer flexibla blockeringsalternativ, men nämns endast i denna kurs och diskuteras inte i detalj.

Metoder för att hantera inlåsningar FRÖKEN Tillgång

Microsoft Access är ett DBMS för flera användare. Den har vissa låsmekanismer att underhålla delning till data och lösa konflikter vid åtkomst till data.

Det finns tre typer av postlåsning i en Access-databas.

· Lås frånvarande. Ikon för detta läge. Om två användare gjorde ändringar i en post samtidigt, kan den som sparar ändringarna först göra det. När den andra användaren försöker spara sina ändringar, visas dialogrutan Skrivkonflikt, som ber honom att antingen spara sin post och förstöra den första användarens ändringar, kopiera hans ändringar till bufferten eller kassera hans ändringar. Detta alternativ kallas optimistisk blockering, eftersom den är baserad på antagandet att en konflikt med dess alternativa utfall inte kommer att inträffa vid redigering.

· Lås föränderligt rekord.
Access låser in det som ändras det här ögonblicket utan att tillåta andra användare att ändra det. Poster som finns i närheten på disken kan också blockeras. Om en annan användare försöker ändra en låst post kommer de inte att kunna göra det

En markör för en blockerad post visas.

Detta alternativ kallas pessimistisk blockering, eftersom det antas att en konflikt definitivt kommer att uppstå. Nackdel: låsets varaktighet är inte begränsad, låset släpps först efter att transaktionen är klar.

· Lås alla poster.
Microsoft Access Låser alla poster för ett formulär eller objekt i arkvyn så att andra användare inte kan ändra eller låsa posterna. Den här inställningen medför allvarliga begränsningar och minskar tydligt prestandan.

Så här ställer du in postblockeringsparametrar:

1. Välj ett lag Kontor → AlternativTillgång. En dialogruta visas alternativTillgång.

2. Expandera fliken Dessutom, kapitel Dessutom.

I grupp Standard öppningsläge du kan välja läge Allmän tillgång eller läge Exklusiv tillgång- öppna en befintlig databas för exklusiv användning av en användare.

I grupp Standardlås den nödvändiga omkopplaren är installerad.

Du kan välja mellan en av tre blockeringsnivåer:

• Frånvarande.

• Låsa redigerbara poster. Endast posten som redigeras är blockerad.
• Blockerar alla poster. Alla tabellposter som visas i formuläret eller tabellen är låsta.

Uppdateringsperiod(er) Antalet sekunder efter vilket Microsoft Access automatiskt uppdaterar poster i datablads- eller formulärvyn.

Antal uppdateringsförsök Antalet gånger Microsoft Access försöker spara en modifierad post som är låst av en annan användare. Möjliga värden är från 0 till 10. Standardvärde: 2.

De konfigurerade alternativen träder i kraft när databasen öppnas igen med kommandot Arkiv, Öppna.

Om du behöver låsning på rekordnivå när du öppnar en databas, måste du markera rutan Öppna databaser med hjälp av låsning på rekordnivå. Om standardblockering på sidnivå krävs, måste den här kryssrutan avmarkeras.

Utöver dessa alternativ för att blockera poster, finns det en annan metod som består av inställning önskat läge arbeta med data i formuläret. För att göra detta måste du öppna formuläret i designläge och på fliken Data Fastighetsfönster för en fastighet Blockera poster välj ett av blockeringsalternativen: saknas, alla poster, ändrad post.

Testfrågor och övningar

1. Definiera en transaktion. Ge exempel på transaktioner.
2. Hur utförs transaktioner i SQL?
3. Namnge och förklara innebörden av transaktionsparametrar? Hur ställer man in parametervärden?
4. Beskriv varje transaktionsisoleringsnivå:
   LÄS ENGAGEMANG, LÄS ENGAGEMANG, REPETERBAR LÄS, SERIASERBAR.
5. Vad är en transaktionslogg? Vilka fält innehåller den? Vad och hur används det?
6. Varför använder DBMS:er datalås vid bearbetning av transaktioner?
7. Namnge och beskriv de låsnivåer som används?
8. Hur ställs datablockeringslägen in i MS ACCESS DBMS?