Blocarea automată nu este permisă în această tranzacție. Transferarea configurației la blocările gestionate. VIII. Calculul cantității și sumei de debitat

Astăzi vom vorbi despre blocări atât la nivelurile 1C 8.3 și 8.2, cât și la nivelul SGBD. Blocarea datelor este un element esențial al oricărui sistem cu mai mulți utilizatori.

Mai jos voi descrie cum funcționează încuietorile și ce tipuri sunt.

O blocare este informația că o resursă de sistem a fost confiscată de un alt utilizator. Se crede că blocarea este o greșeală. Nu, blocarea este o măsură inevitabilă într-un sistem multi-utilizator pentru a partaja resurse.

Numai blocările redundante („suplimentare”) pot provoca daune sistemului, acestea sunt blocări care blochează informații inutile. Este necesar să învățați cum să eliminați astfel de blocaje, acestea pot duce la lucru suboptim sisteme.

Încuietorile din 1C sunt împărțite în mod convențional în obiect și tranzacțional.

Obiectivele sunt, la rândul lor, optimiste și pesimiste. Și tranzacțional poate fi împărțit în gestionat și automat.

Blocaje de obiecte 1C

Acest tip de blocare este complet implementat la nivelul platformei 1C și nu afectează în niciun fel SGBD.

Obțineți gratuit 267 tutoriale video 1C:

Încuietori pesimiste

Această blocare este declanșată atunci când un utilizator a schimbat ceva în formularul de catalog, iar cel de-al doilea încearcă să schimbe obiectul în formular în același mod.

Încuietori optimiste

Această blocare compară versiunile obiectului: dacă doi utilizatori au deschis formularul, iar unul dintre ei a schimbat și a scris obiectul, atunci al doilea la scrierea sistemului va da o eroare că versiunile obiectelor sunt diferite.

Încuietori tranzacționale 1C

Mecanismul de blocare a tracțiunii 1C este mult mai interesant și mai funcțional decât mecanismul de blocare a tracțiunii. Blocările la nivelul SGBD sunt implicate activ în acest mecanism.

Funcționarea incorectă a încuietorilor tranzacționale poate duce la următoarele probleme:

• problema schimbării pierdute;
• problema citirii murdare;
• lectură irepetabilă;
• citind fantome.

Aceste probleme au fost discutate în detaliu în articolul despre.

Blocări tranzacționale automate 1C și SGBD

ÎN mod automat SGBD este pe deplin responsabil pentru blocarea muncii. În acest caz, dezvoltatorul nu este absolut implicat în proces. Cu toate acestea, acest lucru facilitează crearea unui programator 1C Sistem informatic pentru un număr mare de utilizatori cu blocare automată nu este de dorit (în special pentru PostgreSQL, Oracle BD - atunci când modifică datele, blochează complet tabelul).

Diferite grade de izolare sunt utilizate pentru diferite SGBD în modul automat:

• SERIALIZABIL pentru întregul tabel - modul fișier 1C, Oracle;
• SERIALIZABIL pe înregistrare - MS SQL, IBM DB2 atunci când lucrați cu entități non-obiecte;
• CITIRE REPETABILĂ înregistrată - MS SQL, IBM DB2 când lucrați cu entități.

Mod gestionat de blocări tranzacționale 1C și SGBD

Dezvoltatorul unei soluții de aplicații la nivel 1C își asumă întreaga responsabilitate. În acest caz, SGBD instalează suficient nivel inalt izolare pentru tranzacții - READ COMMITED (SERIALIZABIL pentru fișierul SGBD).

Atunci când efectuați orice operație cu baza de date, managerul de blocare 1C analizează posibilitatea de a bloca (captura) o resursă. Încuietorile aceluiași utilizator sunt întotdeauna compatibile.

Două blocări NU sunt compatibile dacă: setate de utilizatori diferiți, au tipuri incompatibile (exclusive / partajate) și setate pe aceeași resursă.

Implementarea fizică a blocărilor într-un SGBD

Fizic, blocările sunt un tabel care se află în baza de date numită master. Tabelul de blocare în sine este denumit syslockinfo.

Tabelul are în mod convențional patru câmpuri:

1. ID-ul sesiunii de blocare SPID;
2. ce anume este blocat de ID-ul RES;
3. tip blocare - S, U sau X MOD(de fapt, există 22 de tipuri în MS SQL, dar numai trei sunt utilizate împreună cu 1C);
4. stare de blocare - poate fi ACORDA(instalat) și AȘTEPTA(așteptând la coadă).

Sistemul 1C: Enterprise vă permite să utilizați două moduri de lucru cu baza de date: modul de blocare automată într-o tranzacție și modul de blocare controlată într-o tranzacție.

Diferența fundamentală între aceste moduri este următoarea. Modul de blocare automată nu necesită ca dezvoltatorul să întreprindă nicio acțiune pentru a gestiona blocările dintr-o tranzacție pentru a face acest lucru. Aceste reguli sunt furnizate de platforma 1C: Enterprise prin utilizarea anumitor niveluri de izolare a tranzacțiilor într-un anumit SGBD. Acest mod de funcționare este cel mai ușor pentru un dezvoltator, dar în unele cazuri (de exemplu, atunci când un număr mare de utilizatori lucrează în același timp), nivelul de izolare a tranzacției utilizat în SGBD nu poate oferi suficient paralelism, care se manifestă în forma unui număr mare de conflicte de blocare în timpul lucrului utilizatorului.

Când funcționează în modul de blocare controlată, sistemul 1C: Enterprise folosește un nivel mult mai scăzut de izolare a tranzacțiilor în SGBD, ceea ce poate crește semnificativ paralelismul utilizatorilor soluției aplicației. Cu toate acestea, spre deosebire de modul de blocare automată, acest nivel de izolare a tranzacției nu poate asigura de la sine că toate regulile pentru lucrul cu datele într-o tranzacție sunt îndeplinite. Prin urmare, atunci când lucrează într-un mod controlat, dezvoltatorul trebuie să gestioneze independent blocările setate în tranzacție.

Într-o formă rezumativă, diferențele dintre interblocări automate și interblocări controlate sunt prezentate în următorul tabel:

	Tipul de blocare	Nivelul de izolare a tranzacției
Încuietori automate
DB de fișiere	De mese	Serializabil
MS SQL Server	Înregistrări
IBM DB2	Înregistrări	Citire repetabilă sau serializabilă
PostgreSQL	De mese	Serializabil
Baza de date Oracle	De mese	Serializabil
Încuietori gestionate
DB de fișiere	De mese	Serializabil
MS SQL Server	Înregistrări	Citiți Angajat
IBM DB2	Înregistrări	Citiți Angajat
PostgreSQL	Înregistrări	Citiți Angajat
Baza de date Oracle	Înregistrări	Citiți Angajat

Setarea modului de blocare în configurație
Configurația are proprietatea. Fiecare obiect de configurare a aplicației are, de asemenea, o proprietate Modul de control al blocării datelor.
Modul de control al blocării datelor pentru întreaga configurație poate fi setat la Automat, controlat (setat implicit pentru configurare nouă) și Automat și controlat... Valorile automate și controlate înseamnă că modul de blocare corespunzător va fi utilizat pentru toate obiectele de configurare, indiferent de valorile setate pentru fiecare dintre obiecte. Valoare Automat și controlatînseamnă că pentru un anumit obiect de configurare va fi utilizat modul specificat în proprietatea sa Modul de control al blocării datelor: Automat sau controlat.
Trebuie remarcat faptul că modul de control al blocării datelor specificat pentru obiectul metadate este setat pentru acele tranzacții care sunt inițiate de sistemul 1C: Enterprise atunci când se lucrează cu datele acestui obiect (de exemplu, atunci când se modifică datele obiectului).
Dacă, de exemplu, operația de scriere a unui obiect se efectuează într-o tranzacție inițiată de dezvoltator (metoda StartTransaction ()), atunci modul de control al blocării datelor va fi determinat de valoarea parametrului Modul de blocare metodă StartTransaction () mai degrabă decât valoarea proprietății obiectului de metadate Modul de control al blocării datelor.
Parametru implicit Modul de blocare are sensul Mod de gestionare a blocării datelor. Automat, prin urmare
pentru a utiliza modul de blocare gestionat într-o tranzacție explicită, trebuie să specificați valoarea acestui parametru
Modul de control DataLock. (are sens să setați acest parametru dacăproprietatea de configurare „Data Lock Control Mode” este setată la „Automatic and Controlled”) .

Lucrul cu blocări gestionate utilizând limbajul încorporat
Obiectul de limbă încorporată este utilizat pentru a gestiona blocările într-o tranzacție Blocare date... Acest obiect poate fi instanțiat folosind constructorul și vă permite să descrieți spațiile de blocare necesare și modurile de blocare. Pentru a seta toate blocările create, utilizați metoda Lock () a obiectului Blocare date... Dacă această metodă este executată într-o tranzacție (explicită sau implicită), blocările sunt achiziționate și vor fi eliberate automat la sfârșitul tranzacției. Dacă metoda Lock () este executată în afara unei tranzacții, atunci nu vor fi achiziționate blocări.

Condițiile sunt stabilite pentru egalitatea valorii câmpului cu valoarea specificată sau pentru apariția valorii câmpului în intervalul specificat.
Condițiile pot fi stabilite în două moduri:

● specificând în mod explicit numele și valoarea câmpului ( Setați valoarea () obiect DataLockElement);
● prin specificarea unei surse de date care conține valorile necesare (proprietatea DataSource a obiectului DataLockElement).

Pentru fiecare element de blocare, poate fi setat unul dintre cele două moduri de blocare:

● partajat,
● excepțional.

Tabelul de compatibilitate a blocării gestionate arată astfel

Modul de blocare partajată înseamnă că datele blocate nu pot fi modificate de o altă tranzacție până la sfârșitul tranzacției curente.
Modul de blocare exclusiv înseamnă că datele blocate nu pot fi modificate de o altă tranzacție până la sfârșitul tranzacției curente și nici nu pot fi citite de o altă tranzacție care dobândește o blocare partajată a acelor date.

Caracteristici de lucru în modul „Automat și controlat”

Când funcționați în modul de control automat și controlat, există două puncte de luat în considerare:

● Indiferent de modul specificat pentru o anumită tranzacție, sistemul va seta controlul corespunzător
blocare.
● Modul de gestionare a blocării este determinat de tranzacția la cel mai înalt nivel. Cu alte cuvinte, dacă o altă tranzacție a fost inițiată în momentul în care a început tranzacția, atunci tranzacția inițiată poate fi efectuată numai în modul setat pentru o tranzacție care rulează deja.

Să luăm în considerare caracteristicile enumerate mai detaliat.
Prima caracteristică este că, chiar dacă modul de gestionare a blocării automate este utilizat pentru o tranzacție, sistemul va seta suplimentar blocările gestionate corespunzătoare atunci când scrie date în această tranzacție. Aceasta implică faptul că tranzacțiile care rulează în modul de blocare gestionată pot a infrunta cu tranzacții,
executat în modul de control al blocării automate.
A doua caracteristică este că modul de gestionare a blocării specificat pentru obiectul metadate din configurație sau specificat la începutul tranzacției în mod explicit (ca parametru al metodei StartTransaction ()), este doar modul „dorit”. Modul efectiv de gestionare a blocării în care va fi executată tranzacția depinde de faptul dacă acest apel pentru a începe o tranzacție este primul sau dacă a început deja o altă tranzacție în această sesiune a sistemului 1C: Enterprise.
De exemplu, dacă doriți să gestionați blocările atunci când scrieți seturi de înregistrări de registre, atunci când postați un document, atunci modul controlat blocările trebuie setate atât pentru registrul în sine, cât și pentru document, deoarece scrierea seturilor de înregistrări ale registrului se va face în tranzacția care a fost deschisă când a fost scris documentul.

Accelerați 1C apăsând câteva butoane 2. Blocaje controlate. 4 septembrie 2011

Dacă citiți metodologia pentru transferul configurației în blocuri gestionate de la 1C, puteți găsi o mulțime de lucruri interesante și înspăimântătoare acolo. De fapt, totul este simplu: În proprietățile de configurare, schimbați modul de blocare a datelor - „Gestionat”. Tot. Vă felicit - tocmai ați trecut la încuietori gestionate. De fapt, totul este oarecum mai complicat - dar nu cu mult.

Pentru început, o mică excursie teoretică - de ce sunt necesare încuietori: Bineînțeles, cine are acces poate fi citit aici: http://kb.1c.ru/articleView.jsp?id=30 1C s-a chinuit să scrie un mesaj destul de articol accesibil despre blocările de date. Pentru cei care nu au acces, voi descrie pe scurt pentru ce sunt încuietorile:

Exemplul 1. Dacă, după activarea blocărilor controlate, nu faceți nimic și, în același timp, începeți să efectuați 2 documente în paralel (unul dintre ele este încă cu o fracțiune de secundă mai devreme), atunci obținem aproximativ următoarea imagine:

Tranzacția 1	Tranzacția 2	Starea reziduurilor
start	|	1 buc
|	start	1 buc
|	|	1 buc
Citind resturile	|	1 buc
|	Citind resturile	1 buc
|	|	1 buc
Anularea din solduri	|	0 buc
|	Anularea soldurilor	-1 BUC
Completare	|
	Completare

Ce este în neregulă aici? Controlul reziduurilor a eșuat. Al doilea document a reușit să citească rămășițele înainte ca primul să reușească să le noteze. În același timp, am văzut că era o bucată pe rămășițe și le-am scris calm după prima. Merită menționat că, după blocare, vor mai fi aici. 2 documente nu vor putea anula resturile în același timp, acest lucru este necesar pentru integritatea logică a bazei de date, dar pentru rezolvarea unei probleme aplicate în acest exemplu greu folositoare.

Acum vom încerca să corectăm situația - în codul de înregistrare a documentului, vom scrie setarea unui blocaj controlat exclusiv chiar înainte de a citi resturile:

Ei bine, acum că ne-am dat seama de ce sunt necesare încuietori, rămâne doar să instalați încuietori gestionate acolo unde este nevoie: și anume - numai acolo unde se efectuează controlul reziduurilor. Dacă în baza dvs. de date un manager are dreptul să dețină un document, indiferent dacă există sau nu un produs (bani) în sold, de ce aveți nevoie de încuietori atunci? Pur și simplu nu le puteți instala, sau vă puteți înregistra și comenta până la momente mai bune. Dacă controlați soldurile, atunci de regulă acestea sunt 3-4 registre, ei bine, maxim 10 este de aprox. Controlul poate fi suspendat atât în ​​proceduri și funcții generale, cât și în modulele setului de înregistrări PH. Codul este extrem de simplu, deschideți sintaxa helper - uitați:

Blocare = DataLock nou;
BlockItem = Blocare. Adăuga ( "Registrul de acumulare. Bunuri în depozite") ;
ElementLocks. SetValue ("Calitate", Referințe. Calitate. FindByCode ("1"));
ElementLocks. Mode = DataLock Mode. Excepţional;
ElementLocks. DataSource = DocumentObject. Ambalaje returnabile;
ElementLocks. UseFromDataSource ("Nomenclatură", "Nomenclatură");
ElementLocks. UseFromDataSource ("Depozit", "Depozit");
Blocare. Bloc ();

De fapt, totul este imediat clar - blocăm „mărfurile în depozite”, setăm 1 dimensiune în mod explicit, luăm valorile altor 2 din sursa de date - PM-ul documentului.

Cei care au citit cărți la 8.2 probabil își amintesc despre „Noua logică a conduitei” - când controlul reziduurilor se efectuează după înregistrarea mișcărilor documentului. Vă întrebați de ce este acest lucru? Dar vom redesena aceeași placă astfel încât controlul reziduurilor și blocarea să fie după înregistrarea mișcărilor:

Tranzacția 1	Tranzacția 2	Starea reziduurilor
start	|	1 buc
|	start	1 buc
|	|	1 buc
Anularea din solduri	|	0 buc
|	Anularea din solduri	-1 BUC
Blocare	|	-1 BUC
Citind resturile	Încercare de blocare	-1 BUC
|	Se așteaptă pe încuietoare	-1 BUC
|	Se așteaptă pe încuietoare	-1 BUC
Completare	Se așteaptă pe încuietoare	-1 BUC
	Blocare	-1 BUC
	Citind resturile	-1 BUC
	|	-1 BUC
	Renunțare	0 buc

Diferența de aspect nu este semnificativă - obținem o creștere a productivității datorită faptului că nu există blocare la momentul scrierii soldurilor (scrierea lor în baza de date, ceea ce necesită de fapt timp). Blocarea are loc mai târziu spre sfârșitul tranzacției, unde se elimină controlul soldurilor negative; acest lucru este destul de satisfăcător pentru logica de afaceri a aplicației.

Știind la ce servesc blocările, le puteți gestiona cu adevărat pe baza sarcinilor de afaceri pe care le rezolvați. SGBD sunt dezvoltate pe baza presupunerii unei protecții maxime a datelor. Dacă, de exemplu, efectuați tranzacții bancare, blocările ar trebui să fie peste tot și la nivelul maxim. Este mai bine să blocați înregistrările inutile decât să permiteți inconsecvența datelor.

Dacă vindeți chifle sau pixuri, probabil că nu aveți nevoie de atât de multe încuietori. Din vina umană și re-sortare, pierdeți de sute de ori mai mult decât ați putea dacă doi utilizatori efectuează simultan două documente de expediere identice.

Pentru a varia între asemenea sarcini diferite SGBD a venit cu niveluri de izolare. Prin setarea nivelului de izolare a tranzacției, puteți spune SGBD-ului care se blochează să se aplice în diferite cazuri (când scrieți și când citiți într-o tranzacție), în diferite cazuri S (puteți citi, nu puteți scrie) sau X (nici nu puteți citi nici scrie) încuietori.

Deci, în modul automat, veți avea aproape întotdeauna un nivel de izolare SERIALIZABIL, care va impune încuietori X acolo unde este necesar și unde nu este necesar, ceea ce vă va strica în mod semnificativ viața.

Și în gestionat, veți avea READ COMMITED, care va suprapune și elibera imediat un blocaj S la citire și X numai la scriere. Cel mai dificil nivel. O blocare rapidă S vă permite doar să verificați dacă aceste date sunt X blocate undeva, ceea ce asigură citirea numai a datelor consistente, așa cum este obișnuit pentru un anumit nivel de izolare și dacă ați citit și efectuat acțiunile recomandate în articolul precedent, atunci nu va exista chiar și blocări S la citire, deci la nivelul SGBD numai scrierea va fi blocată în timpul scrierii - ceea ce este corect și necesar pentru coerența datelor.

Ceea ce faceți cu blocările gestionate este doar decizia dvs. Dar aș recomanda să nu vă grăbiți să le instalați. Am întâlnit companii care aveau un mod de blocare automată, în timp ce cuvântul „încuietori torturate” suna chiar din gura CEO-ului, iar controlul soldurilor negative a fost dezactivat ...

În modul de operare multi-utilizator în 1C, blocările de date sunt un mecanism necesar. Acestea protejează împotriva situațiilor similare vânzării simultane de către doi manageri ai aceluiași produs către clienți diferiți. Platforma 1C oferă două tipuri de încuietori - controlate și automate. Primul dintre modurile de blocare din 1C este optim pentru sistemele cu încărcare mare cantitate mare utilizatori. Să o luăm în considerare mai detaliat.

Caracteristicile modului blocat controlat

Spre deosebire de automat, modul controlat permite sistemului 1C să-și folosească propriul manager de blocare și să aplice reguli SGBD mai puțin stricte. Adică, mecanismul încorporat vă permite să luați în considerare logica de afaceri a aplicației și să setați mai ușor și mai precis restricțiile privind citirea și scrierea datelor. Schimbarea modului de blocare poate oferi câștiguri semnificative de performanță și poate reduce numărul de erori de blocare a tranzacțiilor. Acest lucru se întâmplă din cauza unei verificări suplimentare de către managerul de blocare pentru a respecta restricțiile stabilite în sistem înainte de a trimite cererea către SGBD.

Un dezavantaj semnificativ este că dezvoltatorul trebuie să controleze independent consistența datelor atunci când le introduce și le prelucrează. Este probabil ca după ce activați blocarea gestionată, să fiți nevoiți să scrieți multe verificări pentru a atinge același nivel de securitate. Indiferent, multe companii aleg să treacă la modul gestionat dacă capacitățile o permit.

Atunci când dezvoltați verificări și restricții software, este important să vă amintiți despre particularitatea blocărilor gestionate - oricare dintre acestea sunt păstrate până la sfârșitul tranzacției. Din aceasta rezultă că programatorii trebuie să achiziționeze o blocare mai aproape de sfârșitul unei tranzacții, astfel încât probabilitatea de așteptare să fie minimă. Dacă trebuie să faceți calcule și să notați rezultatul, atunci este mai corect să prescrieți blocarea după calcule.

O altă problemă obișnuită cu blocarea în 1C este importul de documente. Mulți dezvoltatori folosesc o soluție destul de simplă - nu postați documente atunci când încărcați, ci creați numai. Și apoi, folosind un mecanism simplu, conduceți toate datele încărcate într-un mod multithread în funcție de caracteristicile cheie - nomenclatura, partenerii sau depozitele.

Algoritmul pentru trecerea la blocările gestionate 1C arată simplu, dar un administrator necalificat 1C poate face greșeli care vor fi greu de remediat. Cel mai adesea, există probleme cu niveluri de blocare excesive sau insuficiente. În primul caz, vor apărea probleme cu performanța sistemului, până la opriri de urgență ale clusterului de servere. Blocările insuficiente sunt periculoase din cauza erorilor în contabilitate atunci când utilizatorii lucrează în același timp.

Trecerea la modul ghidat

În ciuda faptului că algoritmul complet pentru trecerea la modul de blocare controlat va fi prezentat mai jos, acesta ar trebui să fie efectuat de un specialist cu experiență. Dacă nu înțelegeți principiile mecanismului de blocare în 1C și SGBD, atunci este puțin probabil să puteți scrie corect restricțiile. Dar acest lucru se aplică configurațiilor complexe. Pentru configurații simple Dezvoltatorii începători pot finaliza cu succes procesul de comutare a modului și pot câștiga experiență:

• Primul pas este modificarea modului de control al blocării datelor de configurare. Pentru aceasta, deschideți arborele de configurare din configurator și schimbați modul în proprietățile elementului rădăcină din secțiunea „Compatibilitate”. Selectați elementul „Automat și controlat” astfel încât să nu apară erori înainte ca toate obiectele să fie transferate în noul mod;

• Acum este rândul documentelor. La urma urmei, cu ajutorul lor înregistrăm toate evenimentele care trebuie monitorizate. Trebuie să începeți transferul la încuietori gestionate 1C cu cele mai descărcate documente. În fila „Altele”, specificați modul de blocare „Controlat”;
• Găsim toate registrele asociate cu un document deja procesat și le transferăm într-un mod controlat folosind o metodă similară cu documentele;
• Următorul pas implică găsirea și modificarea tuturor tranzacțiilor cu obiecte modificate. Aceasta include modificări explicite care includ Cuvinte cheie„StartTransaction ()” și toate gestionarele de documente și registre care includ tranzacții;

StartTransaction () Pentru fiecare DocumentOnDelete din ListDocuments CycleDocumentObject = DocumentOnDelete.GetObject (); AttemptDocumentObject.SetDeleteStar (True); Excepție eșec = Adevărat; UndoTransaction (); Raport („Nu s-a șters documentul” + DocumentObject); Încetează; Sfârșitul încercărilor; Sfârșitul ciclului; CommitTransaction ();

• Excludeți operatorul de limbaj de interogare „PENTRU SCHIMBARE”. Puteți să-l înlocuiți cu obiectul DataLock dacă trebuie să modificați cererea și algoritmul pentru apelarea și procesarea acesteia.

Ultimele două etape sunt cele mai dificile și necesită calificări din partea dezvoltatorului, dar sunt garanții menținerii stării de funcționare a contabilității în sistem.

Principalele motive pentru trecerea la blocările gestionate sunt:

• Motivul principal este recomandarea 1C: Expert bazat pe indicații sau 1C: MCC
• Probleme cu munca simultană a utilizatorului ()
• Folosind Oracle, PostgreSQL și.

Costul muncii:

Esența încuietorilor gestionate

Când lucrați în modul automat de blocare a controlului 1C: Enterprise setează un grad ridicat de izolare a datelor într-o tranzacție la nivelul SGBD. Acest lucru vă permite să excludeți complet posibilitatea de a primi date incoerente sau incorecte fără eforturi speciale din partea dezvoltatorilor de aplicații.

Aceasta este o abordare convenabilă și corectă pentru cantitate mică utilizatori activi. Prețul ușurinței de dezvoltare este o anumită cantitate de blocări redundante la nivelul SGBD. Aceste blocări sunt asociate atât cu particularitățile implementării mecanismelor de blocare în SGBD în sine, cât și cu faptul că SGBD nu poate lua în considerare (și nu ține cont) sensul fizic și structura obiectelor 1C: Enterprise metadate.

Când lucrați cu concurență ridicată pentru resurse ( un numar mare de utilizatori) la un moment dat impactul redundanței blocărilor devine vizibil din punct de vedere al performanței în modul paralel.

După ce configurația este trecută într-un mod controlat, platforma activează funcționalitatea suplimentară a „managerului de blocare”, iar integritatea datelor este acum monitorizată nu pe partea DBMS, ci pe partea serverului 1C. Acest lucru mărește încărcarea pe hardware-ul serverului 1C (sunt necesare procesoare mai rapide și mai multă memorie) și, de fapt, introduce chiar o ușoară încetinire (câteva procente), cu toate acestea, îmbunătățește situația cu blocări mult mai semnificativ (mai puține blocări datorită blocărilor un obiect și nu pe o combinație de tabele, mai puțină zonă de blocare și, în unele cazuri, durata de viață a blocărilor de citire este mai scurtă, adică nu până la sfârșitul tranzacției). Acest lucru îmbunătățește paralelismul general.

Noile configurații ale companiei 1C sunt implementate imediat într-un mod controlat.

• Întrebare: Este posibil să faceți mai întâi un audit și apoi să transferați către UB?

Răspuns: Este posibil, auditul va servi ca o justificare suplimentară pentru oportunitatea transferului la blocările gestionate, precum și pentru a evalua contribuția blocărilor automate la încetinirea generală și dacă sunt necesare eforturi suplimentare în afară de transfer.

• Întrebare: Pentru a transfera la UB, ce fel de acces trebuie să oferiți - RDP, TeamViewer? Sau vă pot trimite un fișier de configurare?

Răspuns: Încercăm să nu limităm o tehnologie specifică acces de la distanță, se potrivește orice tehnologie de acces la distanță... Dacă nu contează pentru tine, atunci RDP este mai practic.
Putem efectua optimizarea fișierului de configurare trimis, dar atunci nu vom putea depana unele date reale și va trebui să testați mai atent. Dacă realizăm optimizarea unei copii a bazei de date, atunci o putem testa cu atenție înainte de a vă trimite rezultatul muncii.

• Întrebare: Avem 10 programatori cu normă întreagă care schimbă ceva în configurație în fiecare zi. Se utilizează stocarea configurației partajate. " Cum va fi organizată interacțiunea la transferul către UB? Sau ar trebui ca toți programatorii să plece în vacanță?

Răspuns: De regulă, modificările noastre se fac în câteva zile. Restul timpului este petrecut pentru testare modificările făcute, inclusiv din punctul de vedere al logicii necesare determinate de afacere și nu de considerații tehnice. noi putem face modificări la fișier separat configurare cf, apoi programatorul dvs. îl va adăuga în depozit. Nu trebuie să trimiteți pe nimeni în vacanță... În alte opțiuni de interacțiune, trebuie doar să fiți de acord asupra obiectelor pe care dezvoltatorii dvs. intenționează să le profite, astfel încât să construim un plan de lucru convenabil pentru ambele părți. De regulă, dezvoltatorii dvs. nu trebuie să capteze întreaga configurație sau să ne ofere „roata” pentru o zi.