შეცდომა დაბლოკვის მენეჯერის გამოყენებისას. ტრანზაქციის მონაცემთა დაბლოკვის კონტროლი, მექანიზმი. მართულ საკეტებთან მუშაობა ჩაშენებული ენის გამოყენებით

მართულ საკეტებზე გადასვლის ძირითადი მიზეზები:

• მთავარი მიზეზი არის 1C:Expert-ის რეკომენდაცია ჩვენებაზე დაყრდნობით ან 1C:TsUP
• პრობლემები ერთდროულად მომხმარებლებთან ()
• Oracle-ის, PostgreSQL-ის და .

სამუშაოს ღირებულება:

მართული საკეტების არსი

ავტომატური ჩაკეტვის მართვის რეჟიმში მუშაობისას, 1C:Enterprise ადგენს მონაცემთა იზოლაციის მაღალ ხარისხს ტრანზაქციაში DBMS დონეზე. ეს საშუალებას გაძლევთ მთლიანად გამორიცხოთ არასრული ან არასწორი მონაცემების მიღების შესაძლებლობა აპლიკაციის შემქმნელების მხრიდან განსაკუთრებული ძალისხმევის გარეშე.

ეს არის მოსახერხებელი და სწორი მიდგომა აქტიური მომხმარებლების მცირე რაოდენობისთვის. განვითარების სიმარტივის ფასი არის გარკვეული რაოდენობის ზედმეტი ჩაკეტვა DBMS დონეზე. ეს საკეტები დაკავშირებულია როგორც თავად DBMS-ში ჩაკეტვის მექანიზმების განხორციელების თავისებურებებთან, ასევე იმ ფაქტთან, რომ DBMS არ შეუძლია (და არ ითვალისწინებს) 1C: Enterprise მეტამონაცემების ობიექტების ფიზიკურ მნიშვნელობას და სტრუქტურას.

რესურსებზე (მომხმარებელთა დიდი რაოდენობა) მაღალი წინააღმდეგობით მუშაობისას, რაღაც მომენტში ზედმეტი საკეტების გავლენა შესამჩნევი ხდება პარალელურ რეჟიმში მუშაობის თვალსაზრისით.

კონფიგურაციის მართულ რეჟიმში გადატანის შემდეგ, პლატფორმაში გააქტიურებულია "დაბლოკვის მენეჯერის" დამატებითი ფუნქციონირება და მონაცემთა მთლიანობის კონტროლი ახლა ხორციელდება არა DBMS მხარეს, არამედ 1C სერვერის მხარეს. ეს ზრდის დატვირთვას 1C სერვერის აპარატურაზე (საჭიროა უფრო სწრაფი პროცესორები და მეტი მეხსიერება) და რეალურად იწვევს თუნდაც მცირე შენელებას (რამდენიმე პროცენტი), მაგრამ მნიშვნელოვნად აუმჯობესებს სიტუაციას საკეტებთან დაკავშირებით (ნაკლები ჩაკეტვა ობიექტზე დაბლოკვის გამო და არა მაგიდების კომბინაციაზე, ნაკლები ბლოკირების ზონა და ზოგიერთ შემთხვევაში წაკითხვის ბლოკირების ვადა უფრო მოკლეა, ანუ არა ტრანზაქციის დასრულებამდე). ეს აუმჯობესებს საერთო თანხვედრას.

1C-დან ახალი კონფიგურაციები განხორციელდა დაუყოვნებლივ კონტროლირებად რეჟიმში.

• Question: შესაძლებელია თუ არა ჯერ აუდიტის გაკეთება და შემდეგ FM-ზე გადასვლა?

პასუხი: დიახ, აუდიტი იქნება დამატებითი დასაბუთება მართულ საკეტებზე გადაცემის მიზანშეწონილობისთვის და ასევე შეფასდება ავტომატური საკეტების წვლილი მთლიან შენელებაში და საჭიროა თუ არა დამატებითი ძალისხმევა გადაცემის გარდა.

• კითხვა: UX-ზე გადასასვლელად რა სახის წვდომა უნდა იყოს უზრუნველყოფილი - RDP, TeamViewer? ან შემიძლია გამოგიგზავნოთ კონფიგურაციის ფაილი?

პასუხი: ჩვენ ვცდილობთ არ შემოვიფარგლოთ ერთი კონკრეტული დისტანციური წვდომის ტექნოლოგიით, ეს ასე იქნება ნებისმიერი დისტანციური წვდომის ტექნოლოგია. თუ ამას არ აქვს მნიშვნელობა, მაშინ RDP უფრო პრაქტიკულია.
ჩვენ შეგვიძლია განვახორციელოთ ოპტიმიზაცია გაგზავნილი კონფიგურაციის ფაილზე დაყრდნობით, მაგრამ შემდეგ ჩვენ ვერ შევძლებთ ზოგიერთი რეალური მონაცემების გამართვას და თქვენ მოგიწევთ უფრო ფრთხილად ტესტირება. თუ ჩვენ ვახორციელებთ ოპტიმიზაციას მონაცემთა ბაზის ასლზე, ​​ჩვენ შეგვიძლია შევამოწმოთ იგი უფრო დეტალურად, სანამ სამუშაოს შედეგს მოგცემთ.

• კითხვა: ჩვენ გვყავს 10 სრულ განაკვეთზე პროგრამისტი, რომლებიც ყოველდღიურად ცვლიან რაღაცას კონფერენციაზე. გამოიყენება საერთო კონფიგურაციის მაღაზია." როგორ იქნება ორგანიზებული ურთიერთქმედება UX-ზე გადაცემის დროს? ანუ ყველა პროგრამისტი უნდა გაიგზავნოს შვებულებაში?

პასუხი: როგორც წესი, ჩვენი ცვლილებები ხდება რამდენიმე დღეში. დანარჩენი დრო იხარჯება განხორციელებული ცვლილებების ტესტირებაზე, მათ შორის, ბიზნესის და არა ტექნიკური მოსაზრებებით განსაზღვრული საჭირო ლოგიკის თვალსაზრისით. ჩვენ ჩვენ შეგვიძლია ცვლილებები შევიტანოთ ცალკე კონფიგურაციის ფაილში cf და შემდეგ თქვენი პროგრამისტი ჩადებს მას საცავში. არავის მოუწევს შვებულებაში წასვლა. ურთიერთქმედების სხვა ვარიანტებში, თქვენ უბრალოდ უნდა შეთანხმდეთ, თუ რომელი ობიექტების გადაღებას გეგმავენ თქვენი დეველოპერები, რათა შევქმნათ სამუშაო გეგმა, რომელიც მოსახერხებელია ორივე მხარისთვის. როგორც წესი, თქვენს დეველოპერებს არ სჭირდებათ მთელი კონფიგურაციის გადაღება, ან დღის „საჭის“ მიცემა.

მექანიზმი ტრანზაქციის საკეტებიგამოიყენება კონკურენტული მომხმარებლის წვდომისთვის DBMS-ზე.
ტრანზაქცია არის ერთგვარი უწყვეტი ოპერაცია, რომლის დროსაც იცვლება მონაცემთა ბაზის მდგომარეობა. ეს არის ცვლილების მინიმალური რაოდენობა: თქვენ არ შეგიძლიათ განახორციელოთ ნახევარი ტრანზაქცია; თუ ტრანზაქცია არ დასრულებულა, მონაცემთა ბაზა დაბრუნდება თავდაპირველ მდგომარეობაში.
ვინაიდან ტრანზაქცია იჭერს მონაცემთა მასივს, ამ მასივზე წვდომისას ჩნდება ნიუანსი: მაგალითად, ერთი ტრანზაქცია ცვლის მონაცემებს, მეორე კი ცდილობს წაიკითხოს. კითხვის შედეგი შეიძლება იყოს არასწორი, რადგან არ შეიცავს უახლეს ცვლილებებს. ამიტომ, ტრანზაქციის იზოლაცია მუშაობს DBMS დონეზე. შესაძლებელია შემდეგი იზოლაციის დონეები:

• წაიკითხეთ დაუმორჩილებლად- სანამ ერთი ტრანზაქცია ცვლის მასივს, მეორეს არ შეუძლია მისი შეცვლა, მაგრამ შეუძლია წაიკითხოს. იზოლაციის ყველაზე დაბალი დონე.
• წაიკითხეთ ჩადენილი- სანამ ერთი ტრანზაქცია ცვლის მასივს, მეორეს არ შეუძლია მისი შეცვლა ან წაკითხვა
• განმეორებადი წაკითხვა- სანამ ერთი ტრანზაქცია კითხულობს მასივს, მეორეს არ შეუძლია მისი შეცვლა, მაგრამ შეუძლია წაიკითხოს
• სერიული- სანამ ერთი ტრანზაქცია კითხულობს მასივს, მეორეს არ შეუძლია მისი შეცვლა ან წაკითხვა. ყველა ოპერაცია თანმიმდევრულია. იზოლაციის მაქსიმალური დონე.

თუ 1C: Enterprise კონფიგურაცია დაყენებულია ავტომატური ჩაკეტვის რეჟიმი, შემდეგ ტრანზაქციის იზოლაციის დონე შეირჩევა DBMS-ის მიერ. MS SQL-ის შემთხვევაში, ეს იქნება განმეორებადი წაკითხვის ან სერიული დონის დონეები, ანუ მონაცემთა იზოლაცია მაქსიმუმთან ახლოსაა. ეს წყვეტს მონაცემთა სისწორესთან დაკავშირებულ პრობლემებს, მაგრამ შეიძლება გამოიწვიოს DBMS დონეზე დაბლოკვა მომხმარებლის ინტენსიური მუშაობის დროს. ამიტომ, 1C: Enterprise-ს აქვს საკუთარი ფუნქციონირება საკეტებთან მუშაობისთვის, რომელიც გააქტიურებულია მართული საკეტების რეჟიმის ჩართვით. ამ შემთხვევაში, MS SQL-სთვის ტრანზაქციის იზოლაციის დონე იქნება წაკითხული. თავად პლატფორმა იზოლირებს მონაცემებს DBMS-ზე დაყრდნობის გარეშე.

მართული ჩაკეტვის რეჟიმი ჩართულია კონფიგურაციის თვისებებში:

ასევე, ჩაკეტვის რეჟიმი შეიძლება დაყენდეს კონკრეტული კონფიგურაციის ობიექტებისთვის:

თუ მთლიანობაში კონფიგურაცია დაყენებულია ავტომატური ჩაკეტვის რეჟიმში, მაშინ ყველა რეესტრის ტრანზაქცია იმუშავებს ავტომატურ რეჟიმში, მიუხედავად რეჟიმისა, რომელიც დაყენებულია კონფიგურაციის ობიექტისთვის. თუ მართულია, მაშინ ანალოგიურად, ყველა ტრანზაქცია იქნება მართული. თუ კონფიგურაციის რეჟიმი დაყენებულია ავტომატურზე და კონტროლდება, მაშინ თითოეული ობიექტის რეჟიმი განისაზღვრება მისი პარამეტრებით.

არის ერთი წერტილი ავტომატური და კონტროლირებადი რეჟიმისთვის. ერთი ტრანზაქცია მომხმარებლისთვის შეიძლება წარმოადგენდეს რამდენიმე ტრანზაქციას პლატფორმის თვალსაზრისით. მაგალითად, რეესტრში დოკუმენტის ინტერაქტიულად განთავსება ხდის ორიტრანზაქციები - თავად დოკუმენტის ჩანაწერი და ამ ტრანზაქციის ფარგლებში რეგისტრის მიხედვით რიგების ნაკრების ჩანაწერი. თავად დოკუმენტის დაბლოკვის მართვის რეჟიმიდან და მისი გადაადგილების რეესტრიდან გამომდინარე, შესაძლებელია ოთხი სიტუაცია:

1. დოკუმენტის რეჟიმი ავტომატური, რეგისტრაციის რეჟიმი ავტომატური ->
2. დოკუმენტის რეჟიმი მართული, რეგისტრაციის რეჟიმი მართვა -> ჩანაწერი რეგისტრაციით მართულ რეჟიმში
3. დოკუმენტის რეჟიმი ავტომატური, რეგისტრაციის რეჟიმი კონტროლირებადი -> ჩაწერა რეგისტრაციით ავტომატურ რეჟიმში
4. დოკუმენტის რეჟიმი მართულია, რეგისტრაციის რეჟიმი ავტომატური -> გამონაკლისი (შეცდომა)

კითხვა 06.59 გამოცდის 1C: პლატფორმის პროფესიონალი. ნებისმიერი რეესტრის საშუალებით დოკუმენტის განთავსებისას, თუ დოკუმენტს აქვს ტრანზაქციის ავტომატური დაბლოკვის მართვის რეჟიმი და რეესტრს აქვს მართული რეჟიმი (კონფიგურაციის თვისებებში გამოიყენება ოფცია „ავტომატური და მართული“), მაშინ ასეთი განთავსება გამოიწვევს:

სწორი პასუხი არის მეორე, მას განვსაზღვრავთ პირველი ტრანზაქციის მიხედვით, თუ ის ავტომატურია, მაშინ ყველაფერი ავტომატურია.

1C გამოცდის 06.60 კითხვა: პლატფორმის პროფესიონალი. ნებისმიერი რეესტრის საშუალებით დოკუმენტის განთავსებისას, თუ დოკუმენტს აქვს ტრანზაქციის დაბლოკვის მართვის მართული რეჟიმი, ხოლო რეესტრს აქვს ავტომატური (კონფიგურაციის თვისებებში გამოიყენება "ავტომატური და მართული" ვარიანტი), მაშინ ასეთი განთავსება გამოიწვევს:

1. შეცდომის სიტუაციამდე
2. მთელი ტრანზაქცია ავტომატურად დასრულდება
3. მთელი ტრანზაქცია შესრულდება კონტროლირებადი წესით

სწორი პასუხი არის პირველი, ჩვენ განვსაზღვრავთ პირველი ტრანზაქციის მიხედვით, თუ ის კონტროლდება, მაშინ ეს არის შეცდომა.

კითხვა 06.61 გამოცდის 1C: პლატფორმის პროფესიონალი. ნებისმიერი რეესტრის საშუალებით დოკუმენტის განთავსებისას, თუ დოკუმენტს აქვს ტრანზაქციის დაბლოკვის მართვის ავტომატური რეჟიმი, ხოლო რეესტრს აქვს მართული რეჟიმი (კონფიგურაციის თვისებებში გამოიყენება "მართული" ვარიანტი), მაშინ ასეთი განთავსება გამოიწვევს:

1. შეცდომის სიტუაციამდე
2. მთელი ტრანზაქცია ავტომატურად დასრულდება
3. მთელი ტრანზაქცია შესრულდება კონტროლირებადი წესით

მონაცემთა დაბლოკვის მართვის მექანიზმიტრანზაქციაში საშუალებას გაძლევთ დაბლოკოთ ცვალებადი მონაცემები არა გამოყენებული მონაცემთა ბაზის მართვის სისტემის საშუალებით, არამედ პლატფორმის საშუალებით. მონაცემთა დაბლოკვის ასეთი მართვა ხორციელდება არა DBMS მონაცემების, არამედ დომენის თვალსაზრისით. ამის წყალობით, საკეტები უფრო ზუსტად გამოიყენება და მომხმარებლის კონკურენტულობა იზრდება.

კონფიგურაცია 1C: Enterprise 8-ს შეუძლია იმუშაოს სამი რეჟიმიდან ერთ-ერთში, ტრანზაქციაში საკეტების მართვისთვის:

• ავტო;
• მართული - სტანდარტული რეჟიმი ახალი კონფიგურაციებისთვის;
• ავტომატური და კონტროლირებადი.

IN ავტომატური რეჟიმიმონაცემთა დაბლოკვის მენეჯმენტი იყენებს მონაცემთა ბაზის მართვის სისტემის მიერ მოწოდებულ განმეორებად წაკითხულ და სერიულ ტრანზაქციის იზოლაციის დონეებს. ტრანზაქციის იზოლაციის ეს დონეები უზრუნველყოფს მონაცემთა თანმიმდევრულ და თანმიმდევრულ კითხვას დეველოპერის მხრიდან დაბლოკვის მართვის დამატებითი ძალისხმევის საჭიროების გარეშე.

მართული რეჟიმისაშუალებას გაძლევთ გაზარდოთ მომხმარებლის მუშაობის პარალელიზმი კლიენტ-სერვერის მუშაობის რეჟიმში მონაცემთა ბაზის ტრანზაქციის იზოლაციის უფრო დაბალი დონის გამოყენებით (Read Committed). ტრანზაქციაზე მონაცემების ჩაწერისას, ჩაშენებული ენობრივი ობიექტები ავტომატურად ბლოკავს საჭირო მონაცემებს. დეველოპერს სჭირდება მონაცემთა დაბლოკვის მართვა იმ შემთხვევებში, როდესაც ბიზნეს ლოგიკა მოითხოვს ტრანზაქციის მონაცემების თანმიმდევრულ და თანმიმდევრულ კითხვას.

ავტომატური და კონტროლირებადირეჟიმი საშუალებას გაძლევთ გამოიყენოთ ტრანზაქციის დროს საკეტების მართვის შესაძლებლობა მხოლოდ ზოგიერთი კონფიგურაციის ობიექტისთვის. ეს რეჟიმი შეიძლება გამოყენებულ იქნას მომხმარებლის კონკურენტულობის ოპტიმიზაციისთვის ცალკეული აპლიკაციის ობიექტებთან (მაგალითად, რამდენიმე ყველაზე ინტენსიურად გამოყენებული დოკუმენტი) ან დიდი კონფიგურაციების თანდათანობით გადასასვლელად ტრანზაქციის დაბლოკვის მართვის რეჟიმში.

მოკლედ, განსხვავებები ავტომატური დაბლოკვის რეჟიმში მუშაობისას და კონტროლირებადი ბლოკირების რეჟიმში ნაჩვენებია შემდეგ ცხრილში:

ყველაზე ხშირად, ტრანზაქციაში მონაცემთა დაბლოკვის მართვის აუცილებლობა წარმოიქმნება დოკუმენტების გამოქვეყნების პროცესში, როდესაც თქვენ უნდა წაიკითხოთ და შემდეგ ჩაწეროთ შეცვლილი მონაცემები იმავე ცხრილებზე. მაგალითად, თუ თქვენ აკვირდებით ნაშთებს დოკუმენტის გამოქვეყნებისას.

განსაკუთრებით ამ მიზნით, საკუთრება აქვს დაგროვების რეგისტრებისა და ბუღალტრული აღრიცხვის რეგისტრების კომპლექტებს BlockForChange.

თუ თქვენ გჭირდებათ ნაშთების კონტროლი და შემდეგ გადაადგილების აღრიცხვა იმავე რეესტრში, მაშინ ეს ქონება უნდა იყოს მითითებული საკუთრებაში ამ რეესტრის ჩანაწერების ნაკრებისთვის. მოძრაობები.

ამ თვისების ეფექტი იგივეა, რაც დეველოპერმა დამოუკიდებლად დააინსტალირა (კოდში განსაზღვრული) საჭირო მართული საკეტები 1C:Enterprise 8-ისთვის. პლატფორმა ავტომატურად დააინსტალირებს საჭირო მართულ საკეტს ჩანაწერების ამ ნაკრების დაწერისას. შედეგად, იმავე საკეტის გამოყენებით სხვა მართული ტრანზაქციები ვერ დაიწყებენ ამ რეესტრის კითხვას მიმდინარე ტრანზაქციის დასრულებამდე.

ქვემოთ მოცემულია მონაცემთა დაბლოკვის „მექანიკური“ კონტროლის მაგალითი დაგროვების რეესტრის მონაცემების წაკითხვისას ნივთების აღრიცხვადოკუმენტების დამუშავებაში Გაყიდვების ინვოისი. ამ მაგალითში, მართული საკეტები იქმნება და დაყენებულია მთლიანად ჩაშენებული ენის გამოყენებით.