Selvfølelse og selvkjærlighet 

Kontrollert låsemekanisme. Administrere datalåser i en transaksjon, mekanisme (Transaction Data Lock Control, Mechanism) Arbeide med administrerte låser ved å bruke det innebygde språket

Datalåsstyringsmekanisme i en transaksjon lar deg låse data som kan endres, ikke ved hjelp av databasebehandlingssystemet som brukes, men ved hjelp av plattformen. Slik datalåshåndtering utføres ikke i forhold til DBMS-dataene, men i forhold til fagområdet. Takket være dette påføres låser mer nøyaktig og brukersamtiden øker.

Konfigurasjon 1C:Enterprise 8 kan operere i en av tre moduser for å administrere låser i en transaksjon:

  • auto;
  • administrert - standardmodus for nye konfigurasjoner;
  • automatisk og kontrollert.

I automatisk modus Datalåsadministrasjon bruker de repeterbare lese- og serialiserbare transaksjonsisolasjonsnivåene som leveres av databasebehandlingssystemet. Disse transaksjonsisolasjonsnivåene sikrer konsistent og konsistent lesing av data uten å kreve ytterligere låseadministrasjonsinnsats fra utvikleren.

Administrert modus lar deg øke parallelliteten til brukerarbeid i klient-server-driftsmodus ved å bruke et lavere nivå av databasetransaksjonsisolasjon (Read Committed). Når du skriver data til en transaksjon, låser innebygde språkobjekter automatisk de nødvendige dataene. Utvikleren må administrere datalåser i tilfeller der forretningslogikk krever konsistent og konsistent lesing av data i en transaksjon.

Automatisk og kontrollert modus lar deg bruke muligheten til å administrere låser i en transaksjon kun for noen konfigurasjonsobjekter. Denne modusen kan brukes til å optimere brukerens samtidighet med individuelle applikasjonsobjekter (for eksempel noen av de mest intensivt brukte dokumentene) eller til gradvis å overføre store konfigurasjoner til modus for administrasjon av transaksjonslås.

Oppsummert er forskjellene ved arbeid i automatisk blokkeringsmodus og kontrollert blokkeringsmodus vist i følgende tabell:

Oftest oppstår behovet for å administrere datalåser i en transaksjon i prosessen med å bokføre dokumenter, når du skal lese og deretter skrive endrede data til de samme tabellene. For eksempel hvis du overvåker saldo når du bokfører et bilag.

Spesielt for dette formålet har journalsett over akkumuleringsregistre og regnskapsregistre eiendommen BlockForChange.

Hvis du trenger å kontrollere saldoene og deretter registrere bevegelser i samme register, må denne egenskapen settes for postsettet til dette registeret i eiendommen Bevegelser.

Effekten av denne egenskapen er den samme som om utvikleren uavhengig installerte (foreskrevet i kode) de nødvendige administrerte låsene for 1C:Enterprise 8. Plattformen vil installere den nødvendige administrerte låsen automatisk når dette settet med poster skrives. Som et resultat vil ikke andre administrerte transaksjoner som bruker samme lås kunne begynne å lese dette registeret før den gjeldende transaksjonen er fullført.

Nedenfor er et eksempel på "manuell" kontroll av datalåser ved lesing av akkumuleringsregisterdata Regnskap for varer i dokumentbehandling Salgsfaktura. I dette eksemplet blir administrerte låser opprettet og satt utelukkende ved hjelp av det innebygde språket.

Mekanisme transaksjonslåser brukes for konkurransedyktig brukertilgang til DBMS.
En transaksjon er en slags kontinuerlig operasjon hvor tilstanden til databasen endres. Dette er minimumskvantumet for endring: du kan ikke foreta en halv transaksjon; hvis transaksjonen ikke fullføres, vil databasen bli rullet tilbake til sin opprinnelige tilstand.
Siden en transaksjon fanger opp en rekke data, oppstår det en nyanse i tilgangen til denne matrisen: for eksempel endrer en transaksjon dataene, og en annen prøver å lese den. Leseresultatet kan være feil, fordi vil ikke inkludere de siste endringene. Derfor fungerer transaksjonsisolering på DBMS-nivå. Følgende isolasjonsnivåer er mulige:

  • Les uforpliktende- mens en transaksjon endrer matrisen, kan ikke en annen endre den, men kan lese den. Laveste nivå av isolasjon.
  • Les engasjert- mens en transaksjon endrer matrisen, kan ikke en annen endre eller lese den
  • Repeterbar lesning- mens en transaksjon leser matrisen, kan ikke en annen endre den, men kan lese den
  • Serialiserbar- mens en transaksjon leser matrisen, kan ikke en annen endre eller lese den. Alle operasjoner er sekvensielle. Maksimalt isolasjonsnivå.

Hvis 1C:Enterprise-konfigurasjonen er satt til automatisk låsemodus, så velges transaksjonsisolasjonsnivået av DBMS. I tilfellet med MS SQL vil dette være repeterbare lese- eller serialiserbare nivåer, det vil si at dataisolering er nær maksimum. Dette løser problemer med datariktighet, men kan føre til blokkering på DBMS-nivå under intensivt brukerarbeid. Derfor har 1C:Enterprise sin egen funksjonalitet for å jobbe med låser, som aktiveres ved å aktivere administrerte låser-modus. I dette tilfellet vil transaksjonsisolasjonsnivået for MS SQL være Read committed. Plattformen i seg selv vil isolere dataene uten å stole på DBMS.

Administrert låsemodus er aktivert i konfigurasjonsegenskapene:

Låsemodusen kan også stilles inn for spesifikke konfigurasjonsobjekter:

Hvis konfigurasjonen som helhet er satt til Automatisk låsemodus, vil alle transaksjoner for alle registre fungere i automatisk modus, uavhengig av modusen som er satt for konfigurasjonsobjektet. Hvis administrert, vil alle transaksjoner på samme måte være i administrert. Hvis konfigurasjonsmodusen er satt til Automatisk og kontrollert, vil modusen for hvert objekt bli bestemt av innstillingene.

Det er ett poeng for automatisk og kontrollert modus. En enkelt transaksjon for en bruker kan representere flere transaksjoner fra plattformens synspunkt. For eksempel, interaktivt legge inn et dokument til et register gjør to transaksjoner - en registrering av selve dokumentet, og innenfor denne transaksjonen en registrering av et sett med rader etter register. Avhengig av låsestyringsmodus for selve dokumentet og registeret det flytter, er fire situasjoner mulig:

  1. Dokumentmodus Automatisk, registreringsmodus Automatisk ->
  2. Dokumentmodus Administrert, registermodus Administrert -> post for register i administrert modus
  3. Dokumentmodus Automatisk, registermodus Kontrollert -> post for register i automatisk modus
  4. Dokumentmodus administrert, registreringsmodus Automatisk -> unntak (feil)

Oppgave 06.59 av eksamen 1C: Plattformprofesjonell. Når du poster et dokument gjennom et hvilket som helst register, hvis dokumentet har en automatisk transaksjonslåsstyringsmodus og registeret har en administrert modus (alternativet "Automatisk og administrert" brukes i konfigurasjonsegenskapene), vil slik postering føre til:

Det riktige svaret er det andre, vi bestemmer det ved den første transaksjonen, hvis det er automatisk, så er alt automatisk.

Spørsmål 06.60 av eksamen 1C: Plattformprofesjonell. Når du poster et dokument gjennom et hvilket som helst register, hvis dokumentet har en administrert modus for å administrere transaksjonslåser, og registeret har en automatisk (i konfigurasjonsegenskapene brukes alternativet "Automatisk og administrert"), vil slik postering føre til:

  1. til en feilsituasjon
  2. hele transaksjonen vil bli fullført automatisk
  3. hele transaksjonen vil bli gjennomført på en kontrollert måte

Det riktige svaret er det første, vi bestemmer ved den første transaksjonen, hvis det er kontrollert, så er det en feil.

Spørsmål 06.61 av eksamen 1C: Plattformprofesjonell. Når du poster et dokument gjennom et hvilket som helst register, hvis dokumentet har en automatisk modus for å administrere transaksjonslåser, og registeret har en administrert modus («Administrert»-alternativet brukes i konfigurasjonsegenskapene), vil slik postering føre til:

  1. til en feilsituasjon
  2. hele transaksjonen vil bli fullført automatisk
  3. hele transaksjonen vil bli gjennomført på en kontrollert måte

De viktigste årsakene til å bytte til administrerte låser:

  • Hovedårsaken er anbefalingen fra 1C:Expert basert på vitnesbyrd eller 1C:TsUP
  • Problemer med samtidige brukere ()
  • Bruker Oracle, PostgreSQL og .

Kostnader for arbeid:

Essensen av administrerte låser

Når du arbeider i automatisk låsekontrollmodus, setter 1C:Enterprise en høy grad av dataisolering i en transaksjon på DBMS-nivå. Dette lar deg helt eliminere muligheten for å skaffe ufullstendige eller feil data uten noen spesiell innsats fra applikasjonsutviklernes side.

Dette er en praktisk og riktig tilnærming for et lite antall aktive brukere. Prisen for enkel utvikling er en viss redundant låsing på DBMS-nivå. Disse låsene er assosiert både med særegenhetene ved implementeringen av låsemekanismer i selve DBMS, og med det faktum at DBMS ikke kan (og ikke) ta hensyn til den fysiske betydningen og strukturen til 1C:Enterprise metadataobjekter.

Når du jobber med høye krav om ressurser (et stort antall brukere), blir på et tidspunkt virkningen av redundante låser merkbar når det gjelder ytelse i parallellmodus.

Etter å ha overført konfigurasjonen til administrert modus, aktiveres tilleggsfunksjonaliteten til "lock manager" i plattformen og dataintegritetskontroll utføres nå ikke på DBMS-siden, men på 1C-serversiden. Dette øker belastningen på 1C-servermaskinvaren (raskere prosessorer og mer minne er nødvendig), og introduserer faktisk til og med en liten nedgang (flere prosent), men det forbedrer situasjonen betydelig med låser (færre låser på grunn av låser på et objekt, og ikke på en kombinasjon av tabeller, mindre blokkeringsareal og i noen tilfeller er levetiden til leselåser kortere, dvs. ikke før slutten av transaksjonen). Dette forbedrer den generelle samtidigheten.


Nye konfigurasjoner fra 1C ble implementert umiddelbart i en kontrollert modus.

  • Spørsmål: Er det mulig å gjøre revisjon først og deretter overføre til FM?

Svar: Ja, tilsynet vil tjene som en ekstra begrunnelse for muligheten for å bytte til administrerte låser og også for å evaluere bidraget fra automatiske låser til den generelle nedgangen og om det er behov for ytterligere innsats i tillegg til overføringen.

  • Spørsmål: For å overføre til UX, hva slags tilgang bør gis - RDP, TeamViewer? Eller kan jeg sende deg konfigurasjonsfilen?

Svar: Vi prøver å ikke begrense oss til én spesifikk fjerntilgangsteknologi, det vil gjøre det hvilken som helst fjerntilgangsteknologi. Hvis det ikke spiller noen rolle for deg, er RDP mer praktisk.
Vi kan utføre optimalisering basert på den sendte konfigurasjonsfilen, men da vil vi ikke kunne feilsøke noen reelle data og du må teste mer nøye. Hvis vi utfører optimering på en kopi av databasen, kan vi teste den grundigere før vi gir deg resultatet av arbeidet.

  • Spørsmål: Vi har 10 programmerere på heltid som endrer noe på konferansen hver dag. Et delt konfigurasjonslager brukes." Hvordan vil interaksjonen organiseres under overføringen til UX? Eller skal alle programmerere sendes på ferie?

Svar: Som regel gjøres våre endringer i løpet av et par dager. Resten av tiden går med til å teste endringene som er gjort, inkludert fra synspunktet om nødvendig logikk bestemt av virksomheten og ikke av tekniske hensyn. Vi vi kan gjøre endringer i en egen konfigurasjonsfil cf , og deretter vil programmereren forplikte det til depotet. Ingen trenger å reise på ferie. I andre alternativer for interaksjon trenger du bare å bli enige om hvilke objekter utviklerne planlegger å fange, slik at vi kan bygge en arbeidsplan som er praktisk for begge parter. Som regel trenger ikke utviklerne dine å fange opp hele konfigurasjonen, eller gi oss "rattet" for dagen.

1C:Enterprise-systemet lar deg bruke to moduser for å jobbe med databasen: modusen for automatiske låser i en transaksjon og modusen for kontrollerte låser i en transaksjon.

Den grunnleggende forskjellen mellom disse modusene er som følger. Den automatiske låsemodusen krever ikke at utvikleren tar noen handling for å administrere låser i en transaksjon. Disse reglene er sikret av 1C:Enterprise-systemplattformen gjennom bruk av visse nivåer av transaksjonsisolasjon i et bestemt DBMS. Denne driftsmodusen er den enkleste for utvikleren, men i noen tilfeller (for eksempel med intensivt samtidig arbeid av et stort antall brukere), kan ikke transaksjonsisolasjonsnivået som brukes i DBMS gi tilstrekkelig parallellitet, noe som manifesterer seg i form av et stort antall låsekonflikter når brukere jobber.

Når du opererer i administrert låsemodus, bruker 1C:Enterprise-systemet et mye lavere nivå av transaksjonsisolering i DBMS, noe som kan øke samtidigheten til brukere av applikasjonsløsningen betydelig. Imidlertid, i motsetning til den automatiske låsemodusen, kan dette nivået av transaksjonsisolering ikke lenger i seg selv sikre overholdelse av alle regler for arbeid med data i en transaksjon. Derfor, når du arbeider i administrert modus, er utvikleren pålagt å uavhengig administrere låsene satt i transaksjonen.

Oppsummert er forskjellene ved arbeid i automatisk blokkeringsmodus og kontrollert blokkeringsmodus vist i følgende tabell:

Stille inn blokkeringsmodus i konfigurasjonen

Konfigurasjonen har egenskapen Data Lock Control Mode. Hvert har også en Data Lock Control Mode-egenskap.
Datalåskontrollmodusen for hele konfigurasjonen kan settes til Automatisk, Administrert (standard for en ny konfigurasjon) eller Automatisk og administrert. Verdiene Automatic og Managed betyr at den tilsvarende blokkeringsmodusen vil bli brukt for alle konfigurasjonsobjekter, uavhengig av verdiene som er satt for hvert av objektene. Verdien Automatic and Managed betyr at for et bestemt konfigurasjonsobjekt vil modusen spesifisert i egenskapen Data Locking Control Mode bli brukt: Automatic eller Managed.
Det skal bemerkes at datalåsingskontrollmodusen som er spesifisert for et metadataobjekt er satt for de transaksjonene som initieres av 1C:Enterprise-systemet når du arbeider med dataene til dette objektet (for eksempel når du endrer objektdataene).
Hvis for eksempel operasjonen med å skrive et objekt utføres i en transaksjon initiert av utvikleren (StartTransaction()-metoden), vil datalåsingskontrollmodusen bli bestemt av verdien til parameteren Locking Mode
metoden StartTransaction(), og ikke verdien til metadataobjektegenskapen Data Lock Control Mode.
Som standard er Blocking Mode-parameteren satt til Data Blocking Control Mode Automatic, så for
For å bruke administrert låsemodus i en eksplisitt transaksjon, må du spesifisere verdien av denne parameteren
Datalåskontrollmodus.

Arbeide med administrerte låser ved å bruke det innebygde språket

For å administrere låser i en transaksjon brukes det innebygde språkobjektet DataLock. En forekomst av dette objektet kan opprettes ved hjelp av en konstruktør og lar deg beskrive de nødvendige låseplassene og låsemodusene. For å angi alle opprettede låser, bruk Lock()-metoden til DataLock-objektet. Hvis denne metoden utføres i en transaksjon (eksplisitt eller implisitt), anskaffes låser og frigjøres automatisk når transaksjonen avsluttes. Hvis Lock()-metoden utføres utenfor en transaksjon, vil ingen låser bli anskaffet.

Det er satt betingelser for at feltverdien skal være lik den angitte verdien eller at feltverdien skal være innenfor det angitte området.
Betingelsene kan settes på to måter:

  • ved eksplisitt å spesifisere feltnavnet og -verdien (SetValue()-metoden til DataLockElement-objektet);
  • ved å spesifisere en datakilde som inneholder de nødvendige verdiene (DataSource-egenskapen til DataLockElement-objektet).

For hvert blokkeringselement kan en av to blokkeringsmoduser angis:

  • delt,
  • eksepsjonell.

Tabellen for administrerte låsekompatibilitet ser slik ut:

Delt låsemodus betyr at låste data ikke kan endres av en annen transaksjon før slutten av gjeldende transaksjon.
Eksklusiv låsing betyr at låste data ikke kan endres av en annen transaksjon før slutten av gjeldende transaksjon, og den kan heller ikke leses av en annen transaksjon som har en delt lås på dataene.

Funksjoner for drift i "Automatisk og kontrollert" modus

Når du arbeider i automatisk og kontrollert blokkeringskontrollmodus, bør to funksjoner tas i betraktning:

Uavhengig av modusen som er spesifisert for en gitt transaksjon, vil systemet installere riktig administrert
blokkering.
Låsekontrollmodusen bestemmes av transaksjonen på høyeste nivå. Med andre ord, hvis en annen transaksjon ble startet på det tidspunktet transaksjonen startet, kan den startet transaksjonen kun utføres i modusen som er satt for den allerede kjørende transaksjonen.

La oss vurdere de oppførte funksjonene mer detaljert.

Den første funksjonen er at selv om den automatiske låseadministrasjonsmodusen brukes for en transaksjon, vil systemet i tillegg installere tilsvarende administrerte låser når data skrives i denne transaksjonen. Det følger at transaksjoner utført i administrert låsemodus kan komme i konflikt med transaksjoner utført i automatisk låsestyringsmodus.

Den andre funksjonen er at låseadministrasjonsmodusen spesifisert for et metadataobjekt i konfigurasjonen eller spesifisert eksplisitt når du starter en transaksjon (som en parameter til StartTransaction()-metoden) bare er en "ønsket" modus. Den faktiske låseadministrasjonsmodusen som transaksjonen vil bli utført i, avhenger av om dette er den første samtalen som starter en transaksjon, eller om en annen transaksjon allerede har startet i denne økten av 1C:Enterprise-systemet i det øyeblikket.

For eksempel, hvis du trenger å administrere låser når du skriver sett med registerposter når du posterer et dokument, må den administrerte låsemodusen settes både for selve registeret og for dokumentet, siden skriving av sett med registerposter vil bli utført i transaksjonen åpnet når du skriver dokumentet.