Modaliteti i kontrollit të bllokimit të të dhënave. Mekanizmi i bllokimit të menaxhuar

Mekanizmi bravat e transaksionit përdoret për akses të njëkohshëm të përdoruesit në DBMS.
Një transaksion është një lloj operacioni i pandashëm gjatë të cilit ndryshon gjendja e bazës së të dhënave. Kjo është sasia minimale e ndryshimeve: nuk mund të bësh gjysmë transaksioni; nëse transaksioni nuk është përfunduar, atëherë baza e të dhënave do të kthehet në gjendjen e saj fillestare.
Meqenëse një transaksion kap një grup të dhënash, ka një nuancë në aksesin në këtë grup: për shembull, një transaksion ndryshon të dhënat, ndërsa një tjetër përpiqet t'i lexojë ato. Rezultati i leximit mund të jetë i pasaktë, sepse. nuk do të përfshijë ndryshimet e fundit. Prandaj, izolimi i transaksioneve funksionon në nivelin DBMS. Nivelet e mëposhtme të izolimit janë të mundshme:

• Lexoni të paangazhuar- ndërsa një transaksion ndryshon grupin, tjetri nuk mund ta ndryshojë atë, por mund ta lexojë. Niveli më i ulët i izolimit.
• Lexoni të përkushtuar- ndërsa një transaksion ndryshon grupin, tjetri nuk mund ta ndryshojë dhe as ta lexojë atë
• Lexim i përsëritur- ndërsa një transaksion lexon grupin, tjetri nuk mund ta ndryshojë atë, por mund ta lexojë atë
• E serializueshme- ndërsa një transaksion lexon grupin, tjetri nuk mund ta ndryshojë dhe as ta lexojë atë. Të gjitha operacionet janë të njëpasnjëshme. Niveli maksimal i izolimit.

Nëse konfigurimi 1C: Enterprise është vendosur në modaliteti i kyçjes automatike, atëherë niveli i izolimit të transaksionit zgjidhet nga DBMS. Në rastin e MS SQL, ky do të jetë nivele të leximit të përsëritur ose të serializueshëm, domethënë, izolimi i të dhënave është afër maksimumit. Kjo zgjidh problemet me korrektësinë e të dhënave, por mund të çojë në bllokim në nivelin DBMS gjatë punës intensive të përdoruesit. Prandaj, 1C: Enterprise ka funksionalitetin e vet për të punuar me bravë, i cili aktivizohet duke ndezur modalitetin brava të menaxhuara. Në këtë rast, niveli i izolimit të transaksionit për MS SQL do të angazhohet në Read. Vetë platforma do të izolojë të dhënat pa u mbështetur në DBMS.

Modaliteti i bllokimit të menaxhuar aktivizohet në vetitë e konfigurimit:

Gjithashtu, mënyra e bllokimit mund të vendoset për objekte specifike të konfigurimit:

Nëse konfigurimi në tërësi është vendosur në modalitetin e kyçjes automatike, atëherë të gjitha transaksionet për të gjithë regjistrat do të funksionojnë saktësisht në modalitetin automatik, pavarësisht nga mënyra që është vendosur për objektin e konfigurimit. Nëse Menaxhohet - atëherë në mënyrë të ngjashme, të gjitha transaksionet do të jenë të menaxhuara. Nëse modaliteti i konfigurimit është vendosur në Automatik dhe menaxhohet, atëherë modaliteti për çdo objekt do të përcaktohet nga cilësimet e tij.

Ka një moment për modalitetin automatik dhe të kontrolluar. Një transaksion i vetëm për një përdorues mund të përfaqësojë disa transaksione nga pikëpamja e platformës. Për shembull, rrëshqitja në mënyrë interaktive e një dokumenti nëpër një regjistër bën dy transaksionet - një regjistrim i vetë dokumentit, dhe brenda këtij transaksioni një rekord i një grupi vargjesh sipas rastit. Në varësi të mënyrës së menaxhimit të bllokimit për vetë dokumentin dhe regjistrit që ai lëviz, katër situata janë të mundshme:

1. Modaliteti i dokumentit Automatik, modaliteti i regjistrimit Automatik ->
2. Modaliteti i dokumentit i menaxhuar, modaliteti i rastit të menaxhuar-> Regjistrimi i rastit i menaxhuar
3. Modaliteti i dokumentit Automatik, modaliteti i rastit i menaxhuar -> shkrimi i rastit në modalitetin automatik
4. Modaliteti i dokumentit i menaxhuar, modaliteti i rastit automatik -> përjashtim (gabim)

Pyetja 06.59 e provimit 1C: Platforma profesionale. Kur postoni një dokument në ndonjë libër, nëse dokumenti ka të vendosur modalitetin e menaxhimit të bllokimit automatik të transaksioneve dhe libri ka modalitetin e menaxhuar (opsioni "Automatik dhe i menaxhuar" përdoret në vetitë e konfigurimit), një postim i tillë do të rezultojë në:

Përgjigja e saktë është e dyta, ne përcaktojmë nga transaksioni i parë, nëse është automatike, atëherë gjithçka është automatike.

Pyetja 06.60 e provimit 1C: Platforma profesionale. Kur postoni një dokument në çdo regjistër, nëse dokumenti ka një modalitet të menaxhimit të bllokimit të transaksionit dhe regjistri ka modalitet automatik (në vetitë e konfigurimit, përdoret opsioni "Automatik dhe i menaxhuar"), atëherë një postim i tillë do të çojë në:

1. në një situatë gabimi.
2. i gjithë transaksioni do të kryhet automatikisht
3. i gjithë transaksioni do të ekzekutohet në një mënyrë të menaxhuar

Përgjigja e saktë është e para, ne përcaktojmë nga transaksioni i parë, nëse kontrollohet, atëherë një gabim.

Pyetja 06.61 e provimit 1C: Platforma profesionale. Kur postoni një dokument në ndonjë libër, nëse dokumenti ka të vendosur modalitetin e menaxhimit të bllokimit automatik të transaksioneve dhe libri ka modalitetin e menaxhuar (opsioni "Menaxhuar" përdoret në vetitë e konfigurimit), një postim i tillë do të rezultojë në:

1. në një situatë gabimi.
2. i gjithë transaksioni do të kryhet automatikisht
3. i gjithë transaksioni do të ekzekutohet në një mënyrë të menaxhuar

Sistemi 1C:Enterprise ju lejon të përdorni dy mënyra të punës me bazën e të dhënave: mënyrën e bllokimeve automatike në një transaksion dhe mënyrën e bllokimeve të menaxhuara në një transaksion.

Dallimi themelor midis këtyre mënyrave është si më poshtë. Modaliteti i kyçjes automatike nuk kërkon që zhvilluesi të bëjë asgjë për të menaxhuar bravat në një transaksion për ta bërë këtë. Këto rregulla sigurohen nga platforma e sistemit 1C: Enterprise përmes përdorimit të niveleve të caktuara të izolimit të transaksioneve në një DBMS të veçantë. Kjo mënyrë funksionimi është më e thjeshta për zhvilluesin, megjithatë, në disa raste (për shembull, kur një numër i madh përdoruesish punojnë intensivisht në të njëjtën kohë), niveli i izolimit të transaksionit të përdorur në DBMS nuk mund të sigurojë paralelizëm të mjaftueshëm, i cili manifestohet. në formën e një numri të madh të konflikteve të bllokimit kur përdoruesit punojnë.

Kur vepron në modalitetin e bllokimit të menaxhuar, sistemi 1C:Enterprise përdor një nivel shumë më të ulët të izolimit të transaksionit në DBMS, i cili mund të rrisë ndjeshëm paralelizmin e punës së përdoruesve të zgjidhjes së aplikacionit. Megjithatë, ndryshe nga mënyra e bllokimit automatik, ky nivel i izolimit të transaksionit nuk mund të sigurojë më në vetvete që të plotësohen të gjitha rregullat për të punuar me të dhënat në një transaksion. Prandaj, kur punoni në modalitetin e menaxhuar, zhvilluesi duhet të menaxhojë në mënyrë të pavarur bravat e marra në transaksion.

Në një formë përmbledhëse, ndryshimet midis punës në modalitetin e bllokimit automatik dhe në mënyrën e bllokimit të menaxhuar tregohen në tabelën e mëposhtme:

Vendosja e modalitetit të kyçjes në konfigurim
Konfigurimi ka një veti . Çdo objekt i konfigurimit të aplikacionit ka gjithashtu një veti Modaliteti i kontrollit të bllokimit të të dhënave.
Modaliteti i kontrollit të bllokimit të të dhënave për të gjithë konfigurimin mund të vendoset në Automatik , Menaxhuar (i caktuar si parazgjedhje për një konfigurim të ri) dhe Automatik dhe i kontrolluar. Vlerat "Automatic" dhe "Menaxhuar" nënkuptojnë që mënyra e duhur e bllokimit do të përdoret për të gjitha objektet në konfigurim, pavarësisht nga vlerat e vendosura për secilin prej objekteve. Kuptimi Automatik dhe i kontrolluar do të thotë që për një objekt të caktuar konfigurimi, do të përdoret mënyra e specifikuar në vetinë e tij Modaliteti i kontrollit të bllokimit të të dhënave: Automatik ose i drejtuar .
Duhet të theksohet se mënyra e menaxhimit të bllokimit të të dhënave të specifikuar për një objekt metadata është vendosur për ato transaksione që inicohen nga 1C: Enterprise kur punoni me të dhënat e këtij objekti (për shembull, kur modifikoni të dhënat e objektit).
Nëse, për shembull, operacioni i shkrimit të një objekti kryhet në një transaksion të iniciuar nga zhvilluesi (metoda Fillimi i Transaksionit ()), atëherë mënyra e kontrollit të bllokimit të të dhënave do të përcaktohet nga vlera e parametrit Mënyra e bllokimit metodë Fillimi i Transaksionit (), jo vlera e vetive të objektit të meta të dhënave Modaliteti i kontrollit të bllokimit të të dhënave.
Cilësimi i parazgjedhur Mënyra e bllokimit ka kuptimin DataLockControlMode.Automatic, pra për
Për të përdorur modalitetin e bllokimit të menaxhuar në një transaksion të qartë, duhet të specifikoni vlerën e këtij parametri
DataLockControlControlMode.I kontrolluar (Ka kuptim të vendosni këtë parametër nëseVetia e konfigurimit të modalitetit të kontrollit të bllokimit të të dhënave është caktuar në Automatik dhe i menaxhuar) .

Puna me bravë të menaxhuar duke përdorur gjuhën 1C:Enterprise
Objekti i gjuhës së integruar ka për qëllim të menaxhojë bllokimet në një transaksion LockData. Një shembull i këtij objekti mund të krijohet duke përdorur konstruktorin dhe ju lejon të përshkruani hapësirat e nevojshme të kyçjes dhe mënyrat e kyçjes. Për të vendosur të gjitha bllokimet e krijuara, përdorni metodën Lock() të objektit LockData. Nëse kjo metodë ekzekutohet në një transaksion (të qartë ose të nënkuptuar), bravat merren dhe do të lirohen automatikisht kur transaksioni të përfundojë. Nëse metoda Lock() ekzekutohet jashtë një transaksioni, nuk do të vendosen bllokime.

Janë vendosur kushtet për barazinë e vlerës së fushës me vlerën e specifikuar ose për shfaqjen e vlerës së fushës në intervalin e specifikuar.
Kushtet mund të vendosen në dy mënyra:

● duke specifikuar në mënyrë eksplicite emrin dhe vlerën e fushës (metoda Vendos vlerën() Objekt ElementLockData);
● duke specifikuar një burim të dhënash që përmban vlerat e nevojshme (vetia DataSource e ElementLockData).

Çdo elementi bllokues mund t'i caktohet një nga dy mënyrat e bllokimit:

● të përbashkëta,
● të jashtëzakonshme.

Tabela e përputhshmërisë së bllokimit të menaxhuar duket kështu

Bllokimi i përbashkët do të thotë që të dhënat e kyçura nuk mund të ndryshohen nga një transaksion tjetër deri në fund të transaksionit aktual.
Modaliteti ekskluziv i kyçjes do të thotë që të dhënat e kyçura nuk mund të ndryshohen nga një transaksion tjetër deri në fund të transaksionit aktual dhe gjithashtu nuk mund të lexohen nga një transaksion tjetër që vendos një bllokim të përbashkët në këto të dhëna.

Karakteristikat e punës në modalitetin "Automatik dhe i kontrolluar".

Ka dy gjëra që duhen mbajtur parasysh kur veproni në modalitetin e kontrollit automatik dhe të menaxhuar të bllokimit:

● Pavarësisht nga mënyra e specifikuar për një transaksion të caktuar, sistemi do të vendosë menaxhimin e duhur
duke bllokuar.
● Mënyra e menaxhimit të bllokimit përcaktohet nga transaksioni i nivelit "të lartë". Me fjalë të tjera, nëse një transaksion tjetër ka filluar në kohën e fillimit të transaksionit, atëherë transaksioni që po fillon mund të ekzekutohet vetëm në modalitetin që është vendosur për transaksionin tashmë në ekzekutim.

Le t'i shqyrtojmë këto karakteristika në më shumë detaje.
Karakteristika e parëështë se edhe nëse përdoret modaliteti i menaxhimit automatik të bllokimit për një transaksion, sistemi do të vendosë gjithashtu bllokimet e duhura të menaxhuara kur shkruan të dhënat në këtë transaksion. Nga kjo rezulton se transaksionet që ekzekutohen në modalitetin e bllokimit të kontrolluar mund për t'u përballur me transaksione
ekzekutimi në modalitetin e menaxhimit të bllokimit automatik.
Karakteristika e dytëështë se mënyra e menaxhimit të bllokimit është specifikuar për objektin e meta të dhënave në konfigurim ose specifikuar në mënyrë eksplicite në fillim të transaksionit (si një parametër i metodës Fillimi i Transaksionit ()) është vetëm një mënyrë "e dëshiruar". Modaliteti aktual i menaxhimit të bllokimit në të cilin do të ekzekutohet transaksioni varet nga fakti nëse thirrja e dhënë për të filluar transaksionin është i pari ose një transaksion tjetër ka filluar tashmë në seancën e dhënë 1C: Enterprise deri në këtë moment.
Për shembull, nëse dëshironi të menaxhoni bllokimet kur shkruani grupe të regjistrave të librit kur postoni një dokument, atëherë modaliteti i bllokimit të menaxhuar duhet të vendoset si për vetë librin ashtu edhe për dokumentin, pasi shkrimi i grupeve të regjistrave të librit do të kryhet në transaksionin e hapur kur dokumenti është i shkruar.

Sistemi 1C: Enterprise lejon përdorimin e dy mënyrave të punës me bazën e të dhënave: mënyrën e kyçjeve automatike në një transaksion dhe mënyrën e bllokimeve të menaxhuara në një transaksion.

Dallimi themelor midis këtyre mënyrave është si më poshtë. Modaliteti i kyçjes automatike nuk kërkon që zhvilluesi të bëjë asgjë për të menaxhuar bravat në një transaksion për ta bërë këtë. Këto rregulla sigurohen nga platforma e sistemit 1C: Enterprise përmes përdorimit të niveleve të caktuara të izolimit të transaksioneve në një DBMS të veçantë. Kjo mënyrë funksionimi është më e thjeshta për zhvilluesin, megjithatë, në disa raste (për shembull, kur një numër i madh përdoruesish punojnë intensivisht në të njëjtën kohë), niveli i izolimit të transaksionit të përdorur në DBMS nuk mund të sigurojë paralelizëm të mjaftueshëm, i cili manifestohet. në formën e një numri të madh të konflikteve të bllokimit kur përdoruesit punojnë.

Kur funksionon në modalitetin e bllokimit të menaxhuar, sistemi 1C: Enterprise përdor një nivel shumë më të ulët të izolimit të transaksionit në DBMS, i cili mund të rrisë ndjeshëm paralelizmin e punës së përdoruesve të zgjidhjes së aplikacionit. Megjithatë, ndryshe nga mënyra e bllokimit automatik, ky nivel i izolimit të transaksionit nuk mund të sigurojë më në vetvete që të plotësohen të gjitha rregullat për të punuar me të dhënat në një transaksion. Prandaj, kur punoni në modalitetin e menaxhuar, zhvilluesi duhet të menaxhojë në mënyrë të pavarur bravat e marra në transaksion.

Në një formë përmbledhëse, ndryshimet midis punës në modalitetin e bllokimit automatik dhe në mënyrën e bllokimit të menaxhuar tregohen në tabelën e mëposhtme:

Vendosja e modalitetit të kyçjes në konfigurim

Konfigurimi ka veçorinë e modalitetit të kontrollit të bllokimit të të dhënave. Çdo objekt i konfigurimit të aplikacionit ka gjithashtu një veti të modalitetit të kontrollit të kyçjes së të dhënave.
Modaliteti i kontrollit të bllokimit të të dhënave për të gjithë konfigurimin mund të caktohet në Automatik, Menaxhuar (i caktuar si parazgjedhje për një konfigurim të ri) dhe Automatik dhe Menaxhuar. Vlerat "Automatic" dhe "Menaxhuar" nënkuptojnë që mënyra e duhur e bllokimit do të përdoret për të gjitha objektet në konfigurim, pavarësisht nga vlerat e vendosura për secilin prej objekteve. Vlera Automatic and Managed do të thotë që modaliteti i specifikuar në vetitë e tij Data Lock Management Mode do të përdoret për një objekt të caktuar konfigurimi: Automatik ose Menaxhuar.
Duhet të theksohet se mënyra e menaxhimit të bllokimit të të dhënave të specifikuar për një objekt metadata është vendosur për ato transaksione që inicohen nga 1C: Enterprise kur punoni me të dhënat e këtij objekti (për shembull, kur modifikoni të dhënat e objektit).
Nëse, për shembull, operacioni i shkrimit të një objekti kryhet në një transaksion të iniciuar nga zhvilluesi (metoda StartTransaction()), atëherë mënyra e menaxhimit të bllokimit të të dhënave do të përcaktohet nga vlera e parametrit Lock mode
metoda StartTransaction(), dhe jo vlera e vetive të objektit të meta të dhënave Modaliteti i kontrollit të bllokimit të të dhënave.
Si parazgjedhje, parametri Lock Mode është vendosur në DataLockControlControlMode.Automatic, kështu që për
Për të përdorur modalitetin e bllokimit të menaxhuar në një transaksion të qartë, duhet të specifikoni vlerën e këtij parametri
DataLockControlMode.Menaxhuar.

Puna me bravë të menaxhuar duke përdorur gjuhën 1C:Enterprise

Për të menaxhuar bllokimet në një transaksion, përdoret objekti LockData i gjuhës së integruar. Një shembull i këtij objekti mund të krijohet duke përdorur konstruktorin dhe ju lejon të përshkruani hapësirat e nevojshme të kyçjes dhe mënyrat e kyçjes. Për të vendosur të gjitha bravat e krijuara, përdorni metodën Lock() të objektit DataLock. Nëse kjo metodë ekzekutohet në një transaksion (të qartë ose të nënkuptuar), bravat merren dhe do të lirohen automatikisht kur transaksioni të përfundojë. Nëse metoda Lock() ekzekutohet jashtë një transaksioni, nuk do të vendosen bllokime.

Janë vendosur kushtet për barazinë e vlerës së fushës me vlerën e specifikuar ose për shfaqjen e vlerës së fushës në intervalin e specifikuar.
Kushtet mund të vendosen në dy mënyra:

• duke specifikuar në mënyrë eksplicite emrin dhe vlerën e fushës (metoda SetValue() e objektit DataLockItem);
• duke specifikuar burimin e të dhënave që përmban vlerat e kërkuara (vetia DataSource e objektit DataLockItem).

Çdo elementi bllokues mund t'i caktohet një nga dy mënyrat e bllokimit:

• të përbashkëta,
• të jashtëzakonshme.

Tabela e përputhshmërisë së bllokimit të menaxhuar duket kështu

Bllokimi i përbashkët do të thotë që të dhënat e kyçura nuk mund të ndryshohen nga një transaksion tjetër deri në fund të transaksionit aktual.
Modaliteti ekskluziv i kyçjes do të thotë që të dhënat e kyçura nuk mund të ndryshohen nga një transaksion tjetër deri në fund të transaksionit aktual dhe gjithashtu nuk mund të lexohen nga një transaksion tjetër që vendos një bllokim të përbashkët në këto të dhëna.

Karakteristikat e punës në modalitetin "Automatik dhe i kontrolluar".

Ka dy gjëra që duhen mbajtur parasysh kur veproni në modalitetin e kontrollit automatik dhe të menaxhuar të bllokimit:

Pavarësisht nga mënyra e specifikuar për një transaksion të caktuar, sistemi do të vendosë menaxhimin e duhur
duke bllokuar.
Mënyra e menaxhimit të bllokimit përcaktohet nga transaksioni i nivelit "të sipërm". Me fjalë të tjera, nëse një transaksion tjetër ka filluar në kohën e fillimit të transaksionit, atëherë transaksioni që po fillon mund të ekzekutohet vetëm në modalitetin që është vendosur për transaksionin tashmë në ekzekutim.

Le t'i shqyrtojmë këto karakteristika në më shumë detaje.

Karakteristika e parë është se edhe nëse përdoret modaliteti i menaxhimit automatik të bllokimit për një transaksion, sistemi do të vendosë gjithashtu bllokimet e duhura të menaxhuara kur shkruan të dhëna në këtë transaksion. Nga kjo rrjedh se transaksionet që ekzekutohen në modalitetin e bllokimit të menaxhuar mund të bien ndesh me transaksionet që ekzekutohen në modalitetin e menaxhimit të bllokimit automatik.

Karakteristika e dytë është se modaliteti i menaxhimit të bllokimit i specifikuar për objektin e meta të dhënave në konfigurim ose i specifikuar në mënyrë eksplicite në fillim të transaksionit (si parametër i metodës StartTransaction()) është vetëm një modalitet "i dëshiruar". Modaliteti aktual i menaxhimit të bllokimit në të cilin do të ekzekutohet transaksioni varet nga fakti nëse thirrja e dhënë për të filluar transaksionin është i pari ose një transaksion tjetër ka filluar tashmë në seancën e dhënë 1C: Enterprise deri në këtë moment.

Për shembull, nëse dëshironi të menaxhoni bllokimet kur shkruani grupe të regjistrave të librit kur postoni një dokument, atëherë modaliteti i bllokimit të menaxhuar duhet të vendoset si për vetë librin ashtu edhe për dokumentin, pasi shkrimi i grupeve të regjistrave të librit do të kryhet në transaksionin e hapur kur dokumenti është i shkruar.

Le të shohim se si duket bllokim tipik ekskluziv në 1C.

Mua më duket kështu - dikush mori hua diçka për të kryer ndonjë veprim. Të gjithë të tjerët nuk mund ta bëjnë këtë veprim, ata janë në pritje. Për të përballuar situata të tilla, duhet ditur të paktën disa teoria bazë- të paktën ju duhet kuptojnë, kur vendoset një bravë, çfarë bllokimi vendoset etj.

Unë mendoj se ju e dini shumë mirë këtë në 1C ka dy mënyra mbylljeje: automatike dhe të kontrolluara.

• Në modalitetin automatik gjithçka është e thjeshtë:
  • Çdo lexim vendos S- bllokim.
  • A me çdo hyrje vihetX- bllokim- për më tepër, ka bravë vetëm në serverin DBMS, 1C nuk vendos asnjë bravë.
• Shumë më interesante modaliteti i kontrolluar. Karakteristika kryesore e tij është se bravat funksionojnë ndryshe në 8.2 dhe 8.3.
  • Për shembull, në 8.2 ju çdo lexim do të vënëS- bllokim. Për më tepër, leximi nuk është vetëm një Request.Execute(), por edhe Link.Props, Link.GetObject(), etj.
  • A në 8.3 nuk ka tashmë modalitet përputhshmërie nuk ka bravë leximi. Kështu, 8.3 me siguri fiton për sa i përket paralelizmit.
  • Epo, atëherë fillon më interesante - për shembull, për konstruksionin RecordSet.Read(). në modalitetin e menaxhuar 8.2 do të keni një S-lock në serverin DBMS (kjo është e natyrshme). Por përveç kësaj do të ketë edhe kyçje e përbashkët në serverin 1C, dhe kjo manifestohet si në 8.2 ashtu edhe në 8.3. Dhe problemi kryesor është se ju keni këtë bllokim të përbashkët do të zgjasë deri në fund të transaksionit– derisa transaksioni të përfundojë, të dhënat do të bllokohen.
    Prandaj, rekomandimi numër një është që nëse keni nevojë për një grup regjistrimesh vetëm për lexim, është më mirë të përdorni një pyetje sesa një model objekti. Atëherë nuk do të bllokoni asgjë, dhe nëse e bëni, nuk do të zgjasë shumë.
  • Natyrisht, për çdo ndryshim të të dhënave(regjistrimi, kryerja, fshirja) do vendosni një kyçje ekskluzive në serverin 1C dhe një bllokim ekskluziv në serverin DBMS.

Me këtë tabelë para jush do ta keni shumë më të lehtë të kuptoni se në cilat raste mund të hasni në bllokim.

Kohëzgjatja e bllokimeve në modalitetin e menaxhuar

Gjëja më e rëndësishme kur keni të bëni me flokët është të mbani mend këtë çdo bllokim i menaxhuar do të mbahet gjithmonë deri në fund të transaksionit, Kjo është arsyeja pse është e rëndësishme të minimizohet kohëzgjatja e tij.

Kur keni një zgjedhje se ku të vendosni bllokimin (në fillim të transaksionit ose në fund), është më mirë të zgjidhni në fund, sepse në këtë rast rreziku i pritjes do të jetë shumë më i vogël.

Sa i përket konstruksionit Query.Execute(), nëse është 8.2, bllokimi do të lirohet menjëherë pasi pyetja të ekzekutohet, dhe nëse është 8.3 (ose modaliteti Read Committed Snapshot Isolation është i aktivizuar në MS SQL DBMS), atëherë nuk do të ketë fare bravë. Kështu që nëse keni 8.2 ose 8.3 në modalitetin e përputhshmërisë 8.2 Unë ju marr në çdo mënyrë të mundshme Unë rekomandoj aktiviziminlexoniI përkushtuarpamje e çastitIzolim- në çdo rast, do të rrisni paralelizmin e punës.

Këtu është një shembull tipik: fillimisht mund të vendosni një bllokim, të kryeni disa llogaritje dhe kontrolle (të shihni nëse kërkesa është plotësuar, etj.) dhe vetëm atëherë të përfundoni transaksionin - atëherë koha juaj e bllokimit do të jetë e gjatë. Por është më mirë, nëse ekziston një mundësi e tillë, të veproni ndryshe: së pari, bëni të gjitha llojet e llogaritjeve (kontrolli i mbushjes, etj.), Dhe vendosni një bllokim në fund. Atëherë do të keni më pak kohë bllokimi dhe, në përputhje me rrethanat, rreziku i pritjes gjithashtu do të ulet. Prandaj, përpiquni të aplikoni bllokime eksplicite të menaxhuara ose ndonjë shkrim në bazën e të dhënave sa më afër fundit të transaksionit të jetë e mundur.

Arsyet më të zakonshme të bllokimit

Kërkesë me një skanim

Më shpesh pritja në bravë ndodh në rast të një kërkese jo optimale. Për shembull, ju keni një përdorues Ivanov, i cili, në procesin e postimit të një dokumenti, bllokoi disa artikuj të nomenklaturës - vetëm atë që i nevojitej. Dhe është përdoruesi Petrov, i cili ka ekzekutuar një kërkesë me skanim (Request.Execute()) në transaksion. Dhe nëse, gjatë leximit, kjo kërkesë hyn në nomenklaturën që u bllokua nga Ivanov, atëherë nëse përdorni versionin 8.2 (ose 8.3 në modalitetin e pajtueshmërisë me 8.2), ajo do të ndalet dhe do të presë 20 sekonda si parazgjedhje. Në këtë rast, përdoruesi Petrov do të qëndrojë në pritje, gjë që, natyrisht, nuk do t'i pëlqejë. Si të zgjidhet kjo situatë? Duket se përgjigjja është e qartë - ju mund të merrni dhe rishkruani pyetjen në mënyrë që të mos lexojë rreshta shtesë atëherë gjithçka do të jetë e mrekullueshme.

Dhe nëse kjo kërkesë është platformë? Ose kjo kërkesë përdoret në një konfigurim tipik që nuk mund ta ndryshoni për arsye të dukshme - çfarë duhet të bëni atëherë? Cilat janë opsionet?

Të çaktivizohet modaliteti i përputhshmërisë? Është më e saktë të thuash - kryqëzo veten, krijo një kopje, testo për një javë dhe më pas fik, sepse nëse e fikësh menjëherë, mund të kesh një "fundjavë argëtuese", dhe ndoshta jo vetëm fundjavë.

Një tjetër opsion është aktivizoni modalitetin e versionimit përZNJSQLserver. Unë do të bëj një rezervim menjëherë që situata e përshkruar është e mundur vetëm në një bllokues DBMS, sepse nëse keni një DBMS të versionuar, kjo situatë nuk mund të ekzistojë atje. Dhe nëse aktivizoni Read Committed Snapshot Isolation, atëherë MS SQL fillon të funksionojë pothuajse si një kontroll versioni për ju. DHE pyetja juaj nuk do të bllokojë rreshtat.

Nuk ka "pilula magjike" në 1C, por duke ndezur modalitetinlexoniI përkushtuarpamje e çastitIzolim- më i afërti analoge kjo "pilula magjike". Me veprime minimale, ju mund të zvogëloni menjëherë numrin e pritshmërive në bazën e të dhënave tuaja. Për ta bërë këtë, ju vetëm duhet të ekzekutoni linja të shumta treguar në pamjen e ekranit skenar nëZNJSQL server, dhe ju merrni menjëherë një rritje shumë të mirë të paralelizmit. Sigurisht, kjo ka kuptim vetëm për mënyrën e kontrolluar të kyçjes në konfigurimin 1C. Nuk ka kuptim të aktivizoni modalitetin RCSI në serverin DBMS për modalitetin automatik.

Mungesa e mënyrës së ndarjes së regjistrave

Shpesh, pritshmëritë lindin pikërisht në regjistrat e akumulimit dhe në regjistrat kontabël - në rastin kur aksesohen të njëjtat të dhëna. Për të shmangur pritshmëri të tilla, u shpik modaliteti i ndarjes totale.

Kjo mënyrë mund të aktivizohet në konfiguruesin në vetitë e regjistrit në skedën "Tjetër" - ekziston kutia e zgjedhjes "Lejo totalet e ndara". Kur krijoni një regjistër të ri akumulimi, kjo kuti e kontrollit është aktivizuar tashmë si parazgjedhje. Kështu, zhvilluesit po lënë të kuptohet se është shumë i përshtatshëm për të përdorur këtë veçori, sepse ndihmon të shkruani në regjistër paralelisht, edhe nëse të dhënat tuaja mbivendosen.

Por këtu ka një nuancë - nëse përdorni kontrollin e bilancit për këtë regjistër, atëherë kjo metodë nuk do t'ju ndihmojë në asnjë mënyrë, do t'ju duhet vetëm të shpejtoni kohën e transaksionit në mënyrë që bllokimi të jetë sa më i shkurtër. Por në përgjithësi, përfshirja e një ndarësi total është një veçori e lezetshme dhe unë rekomandoj shumë përdorimin e tij. Sidomos të shëndetshme ndize për regjistrin kontabël, sepse nuk ka pothuajse kurrë një kontroll të mbetjeve.

Lëvizja e kufirit të sekuencës në fshirje

Nëse përdorni një sekuencë në të cilën kufiri ndryshon kur postoni dokumente, atëherë ka shumë të ngjarë që të keni pritje në bravë. Për shembull, dy dokumente që kanë të njëjtën matje në sekuencë nuk do të mund të funksionojnë paralelisht - dikush do të presë dikë.

Çfarë mund të bëhet këtu? Ju vendosni vetia e sekuencës "Mos lëviz automatikisht" dhe bëni detyrë rregulluese, e cila në mbrëmje ju kjo sekuencë do të lëvizë. Këtu është një zgjidhje kaq e thjeshtë - thjesht prishni këto operacione me kohë, atëherë nuk do të ketë më pritshmëri gjatë ditës.

Transaksione afatgjata

Mundohuni të bëni transaksione sa më të shkurtra që të jetë e mundur:

• Ti vesh te gjitha llojet çeqe dhe shlyerje jashtë transaksionit- çdo regjistrim, çdo imponim i bravave duhet të bëhet në fund.
• Në asnjë rast nuk ka kuti dialogu në transaksion nuk ka nevojë të bëhet, veçanërisht nëse përdoret një klient i trashë. Kemi hasur raste të tilla kur kontabilisti, kur poston një dokument, hap një kuti dialogu me butonat "Po" dhe "Jo". Dhe ndërsa ajo vendos se çfarë të shtypë, ndërsa konsultohet me dikë, derisa të thërrasë dikë - kjo dritare do të varet për të, dhe transaksioni do të jetë aktiv gjatë gjithë kësaj kohe, dhe, në përputhje me rrethanat, bllokimi do të jetë gjithashtu aktiv - koha e saj do të jetë shumë e gjatë. Nuk është e nevojshme të bëhet një gjë e tillë.
• Si mund ta shpejtoni edhe më shumë kohën e transaksionit? Mund shpejtoni kodin që ekzekutohet aty. Përshpejtoni kërkesat nëse mund ta bësh. Kjo menjëherë do të japë një rritje të mprehtë të performancës.
• Një tjetër opsion është përshpejtoni shkrimin e regjistrit. Si? Mund të bëhet me softuer, ose me harduer. Për shembull, nëse keni blerë disqe normale SSD, atëherë shpejtësia juaj e shkrimit do të rritet natyrshëm - madje edhe pyetjet do të funksionojnë më shpejt. Dhe, në përputhje me rrethanat, koha e transaksionit gjithashtu do të ulet. Kjo nuk do të thotë që një azhurnim i diskut mund të zgjidhë problemin e bllokimit, por të paktën ju mund ta zbutni këtë efekt - nuk do të jetë më aq i dukshëm.

Përshkallëzimi në modalitetin me shumë fije

Unë me të vërtetë shpresoj që shumë prej jush të përdorin multithreading për të përmirësuar performancën e çdo shkarkimi, ngarkimi, ripostimi të dokumenteve, kur kolapsin sasi të mëdha të dhënash. Ky është një veçori vërtet e fuqishme që ju lejon të arrini disa herë më shpejt. Pasi më duhej të kolapsoja një regjistër që përmbante më shumë se 100 milionë rreshta dhe balancat e parëndësishme duhej të shkarkoheshin diku, duke lënë vetëm një periudhë të caktuar kohore aktuale në bazën e të dhënave. Mendova dhe vendosa të zbatoj përpunimin me shumë fije për këtë rast. Si rezultat, doli që këto fije filluan të bllokojnë njëra-tjetrën, megjithëse të dhënat e tyre nuk mbivendosen fare (secila fije kishte regjistrues të ndryshëm) - megjithatë, kishte një pritje në bllokim.

Rezultoi se në njërin prej përrenjve kishte një dokument të madh e të rëndë që çoi në përshkallëzim. Përshkallëzimi- është kur duke bllokuar mbivendosur jo në ndonjë rresht në tabelë, por për të gjithë tryezën menjëherë. Dhe në rastin tim, në njërën nga temat, e gjithë tabela ishte e mbyllur në përgjithësi.

Në këtë drejtim, unë u futa në algoritëm korrigjim, e cila ka marrë parasysh dokumente të tilla, dhe e shtynë përpunimin e tyre “për më vonë”, që të mos ndodhte një përshkallëzim i tillë dhe flukset të mos bllokonin njëra-tjetrën, të mos bien me gabime.

Kur ndodh zakonisht përshkallëzimi në 1C? Më shpesh, ky është një lloj operacioni i rëndë - mbyllja e muajit, llogaritja e kostos, etj. - kur shumë dokumente fillojnë të kryhen në një transaksion gjigant, e gjithë tabela bllokohet dhe askush nuk mund të punojë në atë kohë - paralelizmi bie. Operacione të tilla duhet të llogariten veçmas dhe të kryhen jashtë orarit të punës., sepse nuk mund t'i përpunosh paralelisht.

Gabim në platformë - Bllokimi kur përdoret kufizuesi i zonës së të dhënave

Ka disa gabime në platformë që çojnë në pritje të panevojshme në bravë. Për shembull, është një bug që më befasoi shumë. Situata është si më poshtë - ne mblodhëm të dhëna për pritjet dhe e pamë atë string Request.Execute() imponon një bllokim ekskluziv të menaxhuar, i cili, në parim, nuk mund dhe nuk duhet të jetë. Kur e pamë këtë, menduam se mjeti "dështoi". Shkarkoi përsëri të dhënat. Të gjitha janë kontrolluar. Në të vërtetë, ajo imponon. Doli që një gabim i tillë u shfaq në platformën 8.3.6. Kur lexoni - nuk ka rëndësi nëse Request.Execute() apo Constant.Read() - në përgjithësi, kur lexoni - platformë aplikuar një bllokim ekskluziv të menaxhuar (X) në një fushë që është kufiri i të dhënave dhe paralelizmi ra menjëherë. Për më tepër, bllokimi ishte thjesht i jashtëzakonshëm.

Këtu është një gabim i tillë i platformës.

Për fatin tonë, klienti që kishte këtë problem nuk e përdori fare këtë ndarës të të dhënave, kështu që ne thjesht e hoqëm atributin nga atributi se është ndarës. Dhe kaq, gabimi është zhdukur. Është rregulluar apo jo, ende nuk e di. Mund të them me siguri që 1C e di për këtë gabim, por kur e rregullojnë atë, për fat të keq, nuk e di. Pra, përgatituni që edhe ju ta keni këtë.

Gabim në platformë - skanimi i indeksit të regjistrit të llogaritjes

Gjithashtu shpesh hasim gabime në platformë kur punojmë me regjistrin e llogaritjes. Për sa i përket performancës, në përgjithësi ka shumë probleme, sepse regjistri i llogaritjes është i vetmi objekt në 1C që nuk ka një indeks grupi. Prandaj, kur shkruani disa qindra rreshta në regjistrin e llogaritjes (nëse ka pak rreshta, atëherë ky gabim nuk riprodhohet), ose pastroni lëvizjet atje (ju shkruani një grup bosh lëvizjesh atje) - do të ketë skanohet indeksi i tabelës së regjistrit të llogaritjes. Dhe meqenëse kjo është një kërkesë platforme, nuk mund ta rregulloni në asnjë mënyrë, dhe meqenëse kjo është një fshirje (zbatohet një bllokim X), aktivizimi i modalitetit Read Committed Snapshot gjithashtu nuk e ndryshon situatën në asnjë mënyrë.

Si rezultat, me prova dhe gabime, u gjet një zgjidhje për këtë problem. Meqenëse regjistri i llogaritjes nuk ka një indeks të grupuar (ka vetëm një jo të grupuar), ne duhej ta çaktivizonim këtë indeks jo të grupuar dhe të krijonim një të ngjashëm, por një grupim. Gjithçka. Pas kësaj, indeksi filloi të përdoret, dhe gjithçka u bë e mrekullueshme. Kështu doli situata. Dhe nëse keni një ZUP dhe jeni përballur me problemin e shkrimit paralel në regjistrin e llogaritjes, mund ta merrni dhe ta përdorni.

Një çështje tjetër me regjistrin e listës së pagave është kur e lexoni atë, që është se pyetja e platformës që lexon të dhënat nga regjistri i listës së pagave skanon gjithashtu indeksin. Por këtu është përfshirja ose e Read Committed Snapshot që tashmë ndihmon, ose, nëse keni 8.3, mund të hiqni modalitetin e përputhshmërisë me 8.2, atëherë nuk do ta keni më këtë problem.

Gabim i platformës - pamundësia e shkrimit paralel në një regjistër periodik të pavarur informacioni

Një gabim shumë i vjetër, i cili është gjithashtu i njohur në 1C, por, megjithatë, ai ende nuk është rregulluar - kjo pamundësia e regjistrimit paralel në një regjistër periodik të pavarur informacioni. Duket se nëse periodat tuaja janë të ndryshme (matjet janë të njëjta, por periudhat janë të ndryshme), mund të shkruani të dhëna paralelisht atje. Por kjo nuk po ndodh, edhe pse duhet të jetë. sepse në serverin 1C, vendoset një bllokim i tepruar sipas datës. Në projekte, kjo situatë nuk është e zakonshme - regjistri i informacionit shumë rrallë bëhet një "fyell i ngushtë" për flokët. Zakonisht problemet lindin për shkak të regjistrit të akumulimit, ose për shkak të regjistrit kontabël. Por megjithatë, nëse hasni në këtë, mund të provoni ta bëni periodën një matje. Po, sigurisht, në këtë rast, ky regjistër informacioni nuk do të formojë më asnjë tabelë virtuale (pjesë e së parës, pjesë e fundit), por mund t'i shkruani me siguri paralelisht dhe mund të krijoni një pyetje për të marrë një copë nga të parat / të fundit vetë.

• Së pari, kaloni në modalitetin e bllokimit të menaxhuar. Unë mendoj se kjo është mjaft e qartë, sepse nëse përdorni modalitetin automatik, mund të mos habiteni as nga pyetjet "Pse kemi pak paralelizëm, pse kemi shumë bravë?" Së pari, kaloni në modalitetin e menaxhuar, dhe nëse pas kësaj keni ende probleme, atëherë tashmë mund ta kuptoni më tej.
• Kur konfigurimi të jetë kaluar në modalitetin e bllokimit të menaxhuar, sigurohuni që ta bëni Modaliteti DBMS duhet të aktivizohetlexoniI përkushtuarpamje e çastitIzolim. Kjo është një domosdoshmëri - menjëherë do të ketë një rritje të mprehtë në punën paralele.
• Përdorni kufizuesin e rasteve. Aty ku nuk ka kontroll të bilancit, duhet të ndizet në mënyrë që të mos ketë pritshmëri.
• DHE Recordset.Read()- Përpiqu fort mos e përdorni për lexim, sepse kjo do të imponojë një bllokim të menaxhuar që do të "varet" deri në fund të transaksionit. Pse ju duhet? Lexoni të dhënat me një kërkesë dhe më pas nuk do të ketë fare bllokime nëse keni 8.3 pa modalitetin e përputhshmërisë ose është aktivizuar modaliteti Read Committed Snapshot.

• Lidhur me kufirin e sekuencës - gjithashtu përpiquni ta pranoni atë si parazgjedhje lëvizin kufirin vetëm me një detyrë të planifikuar gjatë orarit jopune. Mos lëvizni duke mbajtur.
• Ndani transaksionet e mëdha në disa. Në vend që të kryeni një milion dokumente në një transaksion, është më mirë të bëni transaksione të vogla me 100 dokumente, 1000 dokumente secili - edhe më mirë nëse në modalitetin me shumë fije. Do të jetë më e qëndrueshme.
• Çdo llogaritjet, kontrollet etj. bëni jashtë transaksionit. Koha e transaksionit duhet të jetë minimale, sa më e shkurtër të jetë e mundur.

Një shembull i zgjidhjes së problemit të bllokimit

Si tjetër mund të shpëtoni nga pritshmëritë e panevojshme?

Le të themi se keni përfaqësues të shitjeve të cilët, pas përfundimit të ditës së punës (në orën 18:00), dërgojnë dokumente në bazën e të dhënave. Dhe atje, sapo këto dokumente të kalojnë Internet celular vijnë, ata menjëherë përpiqen të boot dhe të kalojnë. Si rezultat, nëse përfaqësuesit e shitjeve kanë porositur të njëjtin artikull nga e njëjta magazinë, ka një pritje sepse po aksesojnë të njëjtat të dhëna, dhe duke qenë se ka një kontroll bilanci, as ndarja totale nuk do të ndihmojë askënd. atëherë duhet të prisni .

Si mund të shmanget kjo? Mund kur ngarkoni dokumente, krijoni, por mos postoni, dhe pastaj shkruani një mekanizëm që, Për shembull, zbaton kjo më tej duke kryer në modalitetin me shumë fije, ku çdo thread do të postojë dokumente në magazinën e tij. Në këtë mënyrë, këto procese ndahen në kohë: filli i parë dërgon dokumente në një magazinë, filli i dytë - në magazinë e dytë, e kështu me radhë. Atëherë problemi do të zgjidhet.

Bllokime dhe pajisje

Si ndikojnë bllokimet në harduer? Kur përballeni me një problem bllokimi, mund të dëshironi të blini një server të ri. Sigurisht, mund të provoni, por ende nuk do të ndryshoni asgjë në imazhin rrënjë. Po, transaksionet do të bëhen më të shpejta, kërkesat do të bëhen më të shpejta. Por vetë problem bllokimi do të mbetet sepse mund të zgjidhet vetëm në nivelin e kodit.

Si ndikon optimizimi i bllokimit në harduer? Për shembull, keni kaluar nga modaliteti automatik në modalitetin e menaxhuar, ose keni aktivizuar Read Committed Snapshot. Ndërsa sistemi është në pritje, ajo pajisje nuk e perdor dhe e ke ne kete rast boshe. A një herë Sistemi juaj funksionon me kapacitet të plotë asnjë pritshmëri, ju menjëherë keni një rritje të mprehtë,. Dhe, në varësi të gjendjes në të cilën ndodhet për momentin, mund të jetë kritike. Për shembull, nëse serveri juaj ishte i ngarkuar me 80%, dhe ju gjithashtu eliminoni bllokimin tuaj, ai në përgjithësi mund të "shtrihet". Kjo duhet të merret parasysh.

ku, optimizimi i pyetjeve-anasjelltas, zvogëlon ngarkesën, prandaj, nëse tashmë jeni duke bërë optimizim, është më mirë të eliminoni bllokimet dhe, nëse është e mundur, të optimizoni kërkesat.

Mjeti i analizës së bllokut

Dhe në përfundim, dua të tregoj mjet me të cilin ju në kohë reale ju mund të shihni se cilat të dhëna janë aktualisht të bllokuara në sistem.

Arsyet kryesore për kalimin në bravë të menaxhuar janë:

• Arsyeja kryesore është rekomandimi i 1C: Ekspert i bazuar në dëshmi ose 1C: TsUP
• Probleme me punën paralele të përdoruesve ()
• Duke përdorur Oracle, PostgreSQL dhe.

Kostoja e punës:

Thelbi i bravave të menaxhuara

Kur punoni në modalitetin e menaxhimit të bllokimit automatik, 1C: Enterprise vendos një shkallë të lartë të izolimit të të dhënave në një transaksion në nivelin DBMS. Kjo bën të mundur që të përjashtohet plotësisht mundësia e marrjes së të dhënave jo integrale ose të pasakta pa ndonjë përpjekje të veçantë nga ana e zhvilluesve të aplikacioneve.

Kjo është një qasje e përshtatshme dhe korrekte me një numër të vogël përdoruesish aktivë. Çmimi i lehtësisë së zhvillimit është një sasi e caktuar bllokimesh të tepërta në nivelin DBMS. Këto bravë lidhen si me veçoritë e zbatimit të mekanizmave të kyçjes në vetë DBMS, ashtu edhe me faktin që DBMS nuk mund (dhe nuk e merr) parasysh kuptimin fizik dhe strukturën e objekteve të meta të dhënave 1C: Enterprise.

Kur punoni me grindje të lartë për burime (një numër i madh përdoruesish), në një moment ndikimi i tepricës së bllokimit bëhet i dukshëm për sa i përket performancës në modalitetin paralel.

Pasi konfigurimi të transferohet në modalitetin e menaxhuar, funksionaliteti shtesë i "menaxherit të bllokimit" aktivizohet në platformë dhe kontrolli i integritetit të të dhënave tani kryhet jo në anën e DBMS, por në anën e serverit 1C. Kjo rrit ngarkesën në harduerin e serverit 1C (duhen procesorë më të shpejtë dhe më shumë memorie), dhe në fakt sjell edhe një ngadalësim të lehtë (disa përqind), por përmirëson shumë më tepër situatën me bravat (më pak bllokime për shkak të bravave për objekt, dhe jo për kombinim tabelash, më pak zonë bllokuese dhe në disa raste më pak se jetëgjatësia e bllokimeve të leximit, pra jo deri në fund të transaksionit). Kjo përmirëson paralelizmin e përgjithshëm.

Konfigurimet e reja të kompanisë 1C zbatohen menjëherë në një mënyrë të kontrolluar.

• Pyetje: A është e mundur që fillimisht të bëhet një audit, e më pas të transferohet në UB?

Përgjigje: Është e mundur që auditimi të shërbejë si një justifikim shtesë për përshtatshmërinë e kalimit në brava të menaxhuara, si dhe për të vlerësuar kontributin e bravave automatike në ngadalësimin e përgjithshëm dhe nëse nevojiten përpjekje shtesë përveç transferimit.

• Pyetje: Për të transferuar në UB, çfarë lloj aksesi duhet të sigurohet - RDP, TeamViewer? Apo mund të më dërgoni skedarin e konfigurimit?

Përgjigje: Ne përpiqemi të mos kufizohemi në një teknologji specifike akses në distancë, mirë çdo teknologji aksesi në distancë. Nëse nuk ka rëndësi për ju, atëherë RDP është më praktik.
Ne mund të optimizojmë sipas skedarit të konfigurimit të dërguar, por atëherë nuk do të jemi në gjendje të korrigjojmë disa të dhëna reale dhe do të duhet të provoni më me kujdes. Nëse kryejmë optimizim në një kopje të bazës, atëherë mund të testojmë plotësisht përpara se t'ju dërgojmë rezultatin e punës.

• Pyetje: Kemi 10 programues me kohë të plotë që ndryshojnë diçka në konferencë çdo ditë. Dyqani i konfigurimit të përbashkët është duke u përdorur." Si do të organizohet ndërveprimi gjatë transferimit në UB? Apo duhet të dërgohen të gjithë programuesit me pushime?

Përgjigje: Si rregull, ndryshimet tona bëhen brenda disa ditësh. Pjesa tjetër e kohës bie në testimin e ndryshimeve të bëra, duke përfshirë nga pikëpamja e logjikës së kërkuar të përcaktuar nga biznesi dhe jo nga konsideratat teknike. ne ne mund të bëjmë ndryshime në një skedar të veçantë konfigurimi cf , dhe më pas programuesi juaj do të kontrollojë në depo. Nuk keni pse të dërgoni askënd me pushime.. Në opsionet e tjera të ndërveprimit, ju vetëm duhet të bini dakord se cilat objekte planifikojnë të kapin zhvilluesit tuaj, në mënyrë që ne të ndërtojmë një plan pune që është i përshtatshëm për të dyja palët. Si rregull, zhvilluesit tuaj nuk kanë nevojë të kapin të gjithë konfigurimin, ose të na japin "timonin" për një ditë.