Viimati vaatlesime kõige lihtsamat meetodit, kasutades sisseehitatud 1C keelt. Praktikas tehingud palju sagedamini kasutatakse koos disainiga. See võimaldab tõrke korral koodi täitmist jätkata, samuti anda kasutajale adekvaatne veateade ning kirjutada info registreerimislogi või logifaili, et süsteemiadministraator saaks seda hiljem analüüsida.

Kui pöördume tehnilise dokumentatsiooni või ITS-ketta poole, näeme, et 1C soovitab tehingu korraldamiseks järgmist meetodit.

Katse //1. Tehingu algus. StartTransaction() ; //2. Tehingu käigus sooritatavate toimingute plokk. //3. Kui kõik toimingud on edukad, sooritame tehingu. CommitTransaction() ; Erand //4. Kui koodi täitmisel ilmnevad vead, tühistage tehing. Tühista tehing() ; //5. Vajadusel märkige sõidupäevikusse. //6. Vajadusel kuvage kasutajale teade. EndAttempt ;

Tegelikult ei vaja kood erilist selgitust. Kui pooleli katsed Tehingukoodi täitmisel tekib tõrge, langeme kohe plokki erand, st. enne meetodit CommitTransaction() me lihtsalt ei jõua sinna. Noh, erandkorras tühistame tehingu vastavalt ja vajadusel kuvame veateate ja kirjutame info logisse. Vigade registreerimine logiraamatusse on väga soovitav, eriti nende toimingute puhul, mis tehakse ilma kasutaja osaluseta (näiteks rutiinsed toimingud). See võimaldab teil viga hiljem analüüsida. Logimise asemel saate korraldada sõnumite saatmise administraatorile meili teel.

Nüüd, olles relvastatud uute teadmistega, proovime muuta artiklis käsitletud koodi. Lubage mul teile meelde tuletada, et arvestasime kataloogi kirjet Kaubad ja inforegistrisse Hind vastavalt järgmisele skeemile:

&Serveris ilma kontekstita StartTransaction() ; //salvestage uus toode Toode = kataloogid. Kaubad. Loo üksus() ; Toode. Nimi = "Hole Punch" ; Toode. Kirjuta() ; //hinda kirja panna RecordSet = teaberegistrid. Hind. CreateRecordSet() ; NewRecord = RecordSet. Lisama() ; NewRecord. Periood = CurrentDate() ; NewRecord. Toode = toode. Link; NewRecord. Summa = 100 ; RecordSet. Kirjuta() ; CommitTransaction() ; Menetluse lõpp

Nüüd paneme tehingu plokki Katse erand. Tõenäoliselt võivad vead ilmneda alles kataloogi või inforegistrisse kandmisel, seega teeme eelettevalmistuse väljaspool tehingut.

&Serveris ilma kontekstita Protseduur RunTransactionOnServer() //loo uus toode Toode = kataloogid. Kaubad. Loo üksus() ; Toode. Nimi = "Hole Punch" ; //Loo rekord koos hinnaga RecordSet = teaberegistrid. Hind. CreateRecordSet() ; NewRecord = RecordSet. Lisama() ; NewRecord. Periood = PraeguneKuupäev() ; NewRecord. Summa = 100 ; //Katse sooritada tehing Proovige StartTransaction(); Toode. Kirjuta() ; NewRecord. Toode = toode. Link; RecordSet. Kirjuta() ; CommitTransaction() ; Erand CancelTransaction() ; Sõnum = Uus sõnum kasutajale; Sõnum. Tekst = ; Sõnum. Teatama() ; Logiregistreerimine( "Toote ja selle hinna salvestamisel ilmnes viga") ; EndAttempt ; Menetluse lõpp

Mida MITTE teha

Neil, kes alles alustavad tehingutega, tekib sageli soov seda nii teha

StartTransaction() ; Proovige StartTransaction(); //Operatsiooniplokk CommitTransaction() ; Erand CancelTransaction() ; EndAttempt ; Katse StartTransaction() ; //Operatsiooniplokk CommitTransaction() ; Erand CancelTransaction() ; EndAttempt ; CommitTransaction() ;

Või ahelas

StartTransaction() ; Iga andmemassiivi ahelast pärit andmete puhul Katse alustada tehingut() ; Andmed. Kirjuta() ; CommitTransaction() ; Erand CancelTransaction() ; EndAttempt ; EndCycle ; CommitTransaction() ;

Esmapilgul tegime kõik vastavalt ettevõtte 1C soovitustele. Kuid tõsiasi on see, et 1C platvorm ei toeta pesastatud tehinguid. See tähendab, et puhttehniliselt on niimoodi võimalik kirjutada. Kuid samal ajal ei moodusta kõik pesastatud tehingud uusi, vaid kuuluvad samasse tipptaseme tehingusse. Sel viisil, kui üks pesastatud tehingutest ebaõnnestub, ei saa järgmist pesastatud tehingut siduda. Süsteem kuvab järgmise teate: "Selles tehingus on juba vigu esinenud!". Näitame seda näitega. Oletame, et otsustame kirjendada kaks kaupa, kumbki oma tehingus. Ja teeme need tehingud pesastatud kolmandasse. Järgmisena tekitame meetodi abil kunstlikult vea esimeses tehingus Tõsta erand:

&Serveris ilma kontekstita Protseduur RunTransactionOnServer() StartTransaction() ; Proovige StartTransaction(); Toode = kataloogid. Kaubad. Loo üksus() ; Toode. Nimi = "Tabel" ; Toode. Kirjuta() ; Tõsta erand "Toote sisestamise viga."; CommitTransaction() ; Erand CancelTransaction() ; Sõnum = Uus sõnum kasutajale; Sõnum. Tekst = ErrorDescription() AttemptStartTransaction() ; Toode = kataloogid. Kaubad. Loo üksus() ; Toode. Nimi = "Tool" ; Toode. Kirjuta() ; CommitTransaction() ; Erand CancelTransaction() ; Sõnum = Uus sõnum kasutajale; Sõnum. Tekst = ErrorDescription() ; Sõnum. Teatama() ; EndAttempt ; CommitTransaction() ; Menetluse lõpp

Selle protseduuri tulemusel näeme sõnumiaknas järgmist.

(ExternalProcessing.TransactionsAtTrying.Form.Form.Form(20)): Viga üksuse kirjutamisel. (ExternalProcessing.TransactionsAtTrying.Form.Form.Form(40)): Viga kontekstimeetodi (Write) kutsumisel: selles tehingus on juba esinenud vigu!

Seega on pesastatud tehingute korraldamine 1C-s täiesti mõttetu.

Võimalikud valikud

Nüüd läheme tagasi valiku juurde, kus me toote ja selle hinna salvestasime. Kui meil tekib tehingu sooritamisel tõrge, on raske aru saada, millal see tekkis – toote või hinna registreerimisel, kuna mõlemad ilmnevad sama katse käigus. Et teha kindlaks, kus viga ilmnes, peame iga kirjutustoimingu ümber tegema ja vältima pesastatud tehinguid. Selleks tutvustame Boole'i ​​muutujat Keeldumine ja sõltuvalt selle väärtusest kõigi toimingute lõpus kinnitame või tühistame tehingu.

&Serveris ilma kontekstita Protseduur RunTransactionOnServer() // Alusta tehingut Keeldu = Vale ; StartTransaction() ; // Proovin toodet salvestada Proovi toodet = kataloogid. Kaubad. Loo üksus() ; Toode. Nimi = "Hole Punch" ; Toode. Kirjuta() ; Erandi ebaõnnestumine = tõene ; Sõnum = Uus sõnum kasutajale; Sõnum. Tekst = "Viga toote salvestamisel"; Sõnum. Teatama() ; EndAttempt ; // Proovin hinda salvestada AttemptRecordSet = Teaberegistrid. Hind. CreateRecordSet() ; NewRecord = RecordSet. Lisama() ; NewRecord. Periood = CurrentDate() ; NewRecord. Toode = toode. Link; NewRecord. Summa = 100 ; RecordSet. Kirjuta() ; Erandi ebaõnnestumine = tõene ; Sõnum = Uus sõnum kasutajale; Sõnum. Tekst = "Viga hinna salvestamisel"; Sõnum. Teatama() ; EndAttempt ; // Kinnitage või tühistage tehing Kui MITTE ebaõnnestumine, siis CommitTransaction() ; Else Tühista tehing() ; EndIf ; Menetluse lõpp

Sama saame teha, kui kordame ja kirjutame mis tahes andmeid tsüklina. Sel juhul saame kõigi vigadega andmete loendi, kui neid on.

Sõna “tehing” jõudis meieni alles üheksakümnendate lõpus. See oli kaasaegse pangandussüsteemi arenemisperiood ja üldine arvutibuum. Siis hakkas see mõiste kõne- ja kirjanduskõnes ilmuma. Ja kuigi tavainimestel esineb programmeerijatega harva probleeme, tuleb pankadega tegeleda kõigil. Peaaegu kõik toimingud – alates konto oleku kontrollimisest kuni keerukate pangasiseste maksete ülekanneteni – võivad kvalifitseeruda tehinguteks. Seda sõna esineb pangatoimingutes peaaegu sagedamini kui selliseid mõisteid nagu "raha" või "krediit". Kuid vähesed panga kliendid mõistavad selle olemust täielikult.

Sõna tähendus

Tehingud on teatud protseduurid mis tahes objektide interaktsiooniks teatud aja jooksul. Sellised protseduurid koostasid programmeerijad. Neil on selge protseduuriline iseloom. Iga tehing koosneb kolmest olulisest komponendist:

• taotlus;
• hukkamine;
• aruanne.

Tavalise tehingu protsess võib olla üsna keeruline, kuid selle protseduuri tulemusel on ainult kaks olekut. See tähendab, et tehing võib lõpule viia või mitte.

Pangatehingud

Mida tähendab sõna "tehing"? Millised protsessid toimuvad selle ilmnemisel? Täpselt öeldes on tehingud kõik raha liikumisega seotud pangatoimingud. Kuid enamasti kasutatakse seda terminit elektrooniliste arvete kasutamisel. Või viitab see otseselt pangakaartidega tehtud tehingutele.

Väljend “tehingute sooritamine” tähendab tehinguid elektroonilist kontot kasutades. See hõlmab kommunaalmaksete tasumist, plastkaardiga poest kaupade ostmist, palkade ja stipendiumide sissemaksmist ning palju muid rahatehinguid.

Tehingute liigid

Panganduses on kahte tüüpi toiminguid:

1. Interneti-tehingud on sularahata rahaga manipuleerimine, ühendades reaalajas pangakeskusega. Kõige ilmsem näide on terminaliga töötamine.
2. Võrguühenduseta tehingud on pangatehingu sooritamine ilma osalejate vahelise otsese kontaktita. Näiteks töötajate palkade krediteerimine. Vahendid debiteeritakse organisatsiooni kontolt ja töötaja saab ainult teate oma arvelduskonto saldo täiendamise kohta.

Pangatehingute olemuse paremaks mõistmiseks kaalume mitmeid nende võimalusi.

Rahatehing

Sellise toimingu lihtsaim näide on ülekanne oma kontode vahel, raha vastuvõtmine või sissemaksmine, sularaha sissemakse sularahaautomaadi või terminali kaudu. Tavaliselt teeb pank selliseid tehinguid ilma vahendustasuta. Keerulisem on olukord kahe erineva isiku vaheliste ülekannetega - sama finantsasutuse piires võib ülekandetasu ulatuda 3%-ni. Kui me räägime erinevatest pankadest riigi sees, siis on vahendustasu veelgi suurem. Kõige kallim on ülekanne välismaistesse asutustesse, kuna lisaks vahendustasule küsivad nad sageli ka nn tehingutasu.

Tõlked

Ülekandmised ühelt kontolt teisele põhjustavad mõnikord tüütuid vigu. Väikseimgi ebatäpsus saaja perekonnanime õigekirjas võib põhjustada elektroonilise turvasüsteemiga manipuleerimise blokeerimise. Automaatne tehing lahendab probleemi. See juhtub näiteks siis, kui raha kantakse saaja saldole pangakaardi numbri abil. See vähendab oluliselt vea tõenäosust. Kui tehing lähtestatakse, tagastatakse raha lihtsalt omaniku saldole. Tõsi, see juhtub kümne-viieteist kalendripäeva jooksul.

Kui saatjal pangakontot ei ole, saate kasutada rahaülekandeteenust. Tuntuimad rahvusvahelised operaatorid on MoneyGram, Western Union, Anelik, Contact jt. Selliste toimingute peamine eelis on suur tehingukiirus. Peamine puudus on üsna kõrge komisjonitasu.

Mida teha, kui tehing ebaõnnestub?

Rahaülekandega seotud ebatavalise olukorra korral peate sellest viivitamatult teavitama panka või terminalioperaatorit. Sel juhul on suur tõenäosus, et raha tagastatakse saatja saldole või kasutatakse seda sihtotstarbeliselt.
Operaator aitab teid, kui:

• Tehingu käigus tekkis rike (programm külmus, elekter kadus) ja raha oli juba läinud. Kõne vihjeliinile salvestab teie taotluse. Pärast vea kontrollimist ja kõrvaldamist saavad spetsialistid toimingu käsitsi lõpule viia.
• Terminal ega sularahaautomaat tehingu kohta kviitungit ei väljastanud. Põhjus võib olla triviaalne – kassalindi puudumine masinas. Pärast operaatoriga ühenduse võtmist pakutakse teile kviitungi duplikaati. Tavaliselt saadetakse see määratud e-posti aadressile.
• Määratud üksikasjades on viga. Raha oli kadunud, kuid saaja ei näinud seda kunagi.
  Operaator saab aidata seda probleemi lahendada: näiteks leida saaja kontonumbrist viga. Sel juhul ei jõua raha kliendini pelgalt turvareeglite tõttu. Pank selliseid vahendeid välja ei võta, vaid neid hoitakse 10 päeva spetsiaalsel ajutisel kontol. Kui saatja võtab finantsasutusega õigel ajal ühendust, märgib ära tehingu tegemise aja, ülekande summa ja vastab mitmele küsimusele, siis raha blokeering tühistatakse. Pärast tehingutasu mahaarvamist tagastatakse summa saatja saldole.

Nagu näete, on pangatehingud huvitav, vajalik protseduur meie igaühe elus. Järgmisel korral lihtsat ülekannet tehes või kaardilt raha välja võttes mõelge, kui palju lihtsamaks sellised manipulatsioonid meie elu teevad. Tõenäoliselt teate nüüdseks juba, mis tehingud on. Selle sõna tähendus pole teile saladus.

Paljud inimesed mõtlevad, mis on tehing? See sõna tuleb ju kogu aeg ette, eriti kui inimene töötab rahaga. Kui võtta globaalselt - andmevahetusoperatsioonide jada, mille järel tehakse süsteemimuudatusi.

Kõige sagedamini kasutatakse seda terminit rahaülekannete tegemisel ja kaupade ostmisel. See võib olla:

• Sularaha väljavõtmine sularahaautomaadist või pangakontorist;
• Teatud arvu aktsiate ostmine börsil;
• Tasumine poes kaardiga.

Niipea kui toiming on kinnitatud ja raha saadetud, loetakse tehing edukalt sooritatuks. Ostja või asutuse kliendi kontolt võetakse raha välja ja kaup kantakse üle eraisikule. Võib öelda, et tehing on viis inimese kontolt raha vabatahtlikuks ülekandmiseks teenust osutavale isikule. Kõik tehingud registreeritakse finantsasutuse andmebaasis. Vahet pole, kas operatsioon õnnestus või mitte. Näiteks rahaliste vahendite ebaõige krediteerimise korral pangakaardile.

Kuid ärge arvake, et tehingu mõiste kehtib ainult finantssektori kohta. Seda terminit kasutavad sageli ka IT-ettevõtted, eriti mis puudutab andmebaaside programmeerimist. Sel juhul tähendab see termin andmebaasis tehtud muudatuste teatud jada.

Siin on ka kaks rakendusvõimalust. Kui toiming on heaks kiidetud, määratakse sellele "Kinnita", kui aga mingil põhjusel keeldutakse, siis "Tagasiminek". Enamasti juhtub see siis, kui nad soovisid jagada ühte numbritest nulliga või sisestasid summa, mis ei vasta varem andmebaasi sisestatule.

Liigid

Kõige tavalisem tehingu kasutamise juhtum on panga maksekaardiga maksmine mis tahes kaubanduskeskuse, kaupluse või finantsasutuse territooriumil. Toiming algab siis, kui omanik soovib kauba eest tasuda, misjärel annab ta oma pangakaardi kassa eest vastutavale töötajale.

Järgmisena asetatakse kaart spetsiaalsesse terminali, kus peate ainult kinnitama järgneva toimingu. Selleks tuleb sisestada andmed ja etteantud PIN-kood. Järgmisena otsustab terminal, kas sisestatud parool oli õige või tuleks see tagasi lükata. Igal juhul salvestatakse teave tehingu kohta konkreetsesse andmebaasi. See juhtub andmete edastamise tõttu seda kaarti teenindavasse maksesüsteemi. Ja juba selles etapis toimub sisestatud andmete autentsuse täielik kontroll. Need võivad ju makselehel olla, aga ei pruugi.

Kuid kui kõik on õige, on tehing edukalt lõpule viidud ja saadetakse otse väljastanud panka. Selle maksekaardi valmistamine toimus tema kaudu. Seejärel saadetakse teave tehingu kohta pressikeskusesse, kus määratakse teave maksesüsteemi kasutusõiguste kohta.

Tasub teada, et kui mõnes etapis tuvastatakse viga või andmete lahknevus, siis tehingust lihtsalt keeldutakse.

Kasutusvaldkonnad

Erinevates rakendusvaldkondades kasutatakse sõna "tehing" jaoks erinevaid tähiseid:

• Majandusteadus viitab raha ülekandmisele ühelt vookontolt teisele. See kehtib eriti ostu-müügitehingute kohta;
• Pangaautomaatidega toimingud toovad kaasa sularaha väljastamise kliendile, kes kasutas selle vastuvõtmiseks pangakaarti või kontonumbrit;
• Poliitiline seletus toob kaasa kokkuleppe kahe osapoole vahel vastastikku kasulike tingimuste kohta.

Palju oleneb panga väljastatud kaardist. Deebet- ja krediitkaarte käsitletakse erinevalt. Otsene mõju on ka sisselogimise prioriteedil, mille määrab kaardi väljastanud finantsasutus. Sõltuvalt nendest teguritest on operatsiooni kiirus erinev.

Tehingud väikese rahasummaga tunduvad lihtsamad. Kui inimene on parameetrites määranud teatud seadistuse, on tal võimalus tehingu käigus parooli mitte sisestada. See viiakse läbi automaatselt ja kui kontol on piisav kogus raha, kantakse need maha ning teave toimingu kohta salvestatakse andmebaasi.

Isegi rahandusega täiesti mitteseotud valdkonnad kasutavad „tehingute” mõistet. Näitena tuuakse psühholoogia. Selle valdkonna spetsialistid nimetavad tehingut stiimulite vahetamiseks, mis tekivad kahe inimese vestluse käigus. See rakendus on mõnevõrra kauge, kuid sellel on õigus eksisteerida. Nüüd teate, mis tehingud on.

Tehingute kohta peate teadma vähemalt ülaltoodud teavet, kuna ilma nendeta on tänapäeva maailmas lihtsalt võimatu. See tähendab, et teil peaks siiski olema minimaalne idee.

See artikkel sisaldab suures osas teoreetilist teavet, mis on vajalik tehingute ja lukkude olulisuse mõistmiseks 1C:Enterprise'is ja DBMS-is, ning see kajastub ka 1C:Enterprise'i toimivuses. Artiklis kirjeldatakse populaarselt tehingute ja lukkude vahelisi seoseid isolatsioonitasemete ja samaaegsusprobleemide kaudu.
See artikkel ei anna praktilisi nõuandeid konkreetsete probleemide lahendamiseks, kuid on aluseks järgmiste artiklite mõistmiseks, mis kirjeldavad samme tehingute ja lukkudega seotud 1C:Enterprise jõudluse optimeerimiseks ja parandamiseks.

Tootlikkus on otseselt seotud 1C:Enterprise TRANSACTIONSiga

"Lukusta konflikt tehingu ajal:
Microsoft OLE DB pakkuja SQL Serveri jaoks: Lukustustaotluse ajalõpu periood on ületatud.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, olek=34, raskusaste=10, native=1222, rida=1"

Kui 1C:Enterprise tekitab sarnase tõrke, siis on teil tegemist blokeerimisega seotud jõudlusprobleemidega. Sellise probleemi lahendamine ei ole alati triviaalne ja nõuab teatud eriteadmisi DBMS-i ja 1C:Enterprise'i toimimise kohta, mida ei 1C:Enterprise'i programmeerijatel ega süsteemiadministraatoritel sageli pole. Järgmine artiklite seeria peaks täitma nende teadmiste lünga.

Tehingud 1C: Ettevõte

Tehing on jagamatu andmetega tehtavate toimingute jada. See töötab kõik või mitte midagi põhimõttel ja tõlgib andmebaasi
ühest terviklikust olekust teise terviklikku olekusse. Kui mõni tehingutoimingutest ei ole mingil põhjusel käivitatav või tekib mingisugune süsteemihäire, naaseb andmebaas olekusse, mis oli enne tehingu algust (tehing keritakse tagasi).

Tehingumehhanismile (tuntud lühendiga ACID) on mitmeid nõudeid: Aatomilisus (Aatomilisus), Järjepidevus (Järjepidevus), Isolatsioon (Isolatsioon), Jätkusuutlikkus (Vastupidavus)

Aatomilisus (Aatomilisus). See nõue on, et kõik andmed, millega tehing toimib, peavad olema kas kinnitatud ( pühenduma), või tühistatud ( tagasipööramine). Ei tohiks tekkida olukorda, kus ühed muudatused kinnitatakse ja teised tühistatakse.

1C:Enterprise'i puhul tagavad Transaction Atomicity atribuudid andmete loogilise terviklikkuse. Näiteks dokumendi salvestamisel kirjutatakse selle päiseandmed ühte füüsilisse DBMS-i tabelisse ja tabeliosa andmed teise. Dokumendi registreerimine tehingus tagab mõlema füüsilise tabeli (päised ja tabeliosad) andmete järjepidevuse (tabeli osa pole võimalik kirjutada ilma päiseta või vastupidi).

Isolatsioon (Isolatsioon). Tehingud tuleb sooritada autonoomselt ja teistest tehingutest sõltumatult. Kui palju konkureerivaid tehinguid töötab samaaegselt, peidetakse kõik konkreetse tehingu värskendused teiste eest, kuni tehing on tehtud. Tehingute eraldamisel on mitu taset, mis võimaldavad teil valida jõudluse ja andmete terviklikkuse seisukohalt optimaalseima lahenduse. Nende tasemete rakendamise peamine meetod on lukustamine, mida käsitletakse selles artiklis.

Tehingulogi (SQL Server)

Igal SQL Serveri andmebaasil on tehingulogi, mis salvestab kõik iga tehinguga tehtud andmete muudatused. Kui tehing mingil põhjusel ei jõudnud lõpule (tagasi või katkestati), tühistab SQL-server tehingulogi kasutades kõik tehingutoimingud järjestikku vastupidises järjekorras. See tähendab, et pikaajaline kirjutamistehing võtab kaua aega ja see tühistatakse.

Tehingulogi on andmebaasi kriitiline komponent ja süsteemi tõrke korral võidakse nõuda andmebaasi ühtlusse viimist. Tehingute logi ei tohi kustutada ega muuta, välja arvatud juhul, kui võimalikud tagajärjed on teada.

Olenevalt andmebaasi seadistustest (taastamismudel) saab tehingute tehingute logi kärpida (vanad tehinguandmed kustutatakse) kas automaatselt või käsitsi (taastamismudel=FULL). Mõnikord unustab süsteemiadministraator logi kärpida ja võib ilmneda tõrge: " Andmebaasi tehingulogi on täis"

Füüsiliselt asub MS SQL Serveri DBMS-i tehingulogi .LDF-failis (ja andmefail on .MDF).

Tehingud süsteemis 1C:Enterprise

Süsteem 1C:Enterprise kutsub andmebaasi salvestatud teabe muutmisega seotud toimingute tegemisel kaudselt välja tehinguid. Näiteks kutsutakse tehingu käigus kõik objekti- ja kirjekomplekti moodulites asuvad sündmuste töötlejad, mis on seotud andmebaasiandmete muutmisega.

Näide kaudsest tehingust: sündmuste jada vormilt dokumendi postitamisel

Praktikas saate kindlaks teha, et 1C:Enterprise objektikirje (näiteks dokument) on TV tehing, viies läbi järgmise katse: Proovige postitada ja sulgeda (klõpsake dokumendivormil "OK") uus dokument, teades ette, et seda ei postitata (näiteks märkides mahakandmisele kuuluva kauba suure koguse) . Kuna saldosid kontrollitakse dokumendi konteerimise etapis, siis töötlejas "Töötleb postitamist()", peaks selleks hetkeks olema dokument ise juba andmebaasi kirjutatud, kuna dokument kirjutatakse varem "BeforeWriting()" ja "" vahele. OnWriting()" sündmused. Kuid peale veateate ilmumist (vajalik kogus puudub) leiame, et dokumenti pole andmebaasis kantud (muutmislipp “*” jääb alles ja dokumenti ei kuvata nimekirjas). See juhtub seetõttu, et tehing tühistatakse pärast tõrke ilmnemist (tagasi).

Otsese tehingukõne kasutamine

meetod StartTransaction() võimaldab teil tehingut avada. Kõik muudatused andmebaasi teabes, mis on tehtud järgnevate avaldustega, saab seejärel kas täielikult aktsepteerida või täielikult tagasi lükata. Tehtud muudatuste vastuvõtmiseks kasutage meetodit CommitTransaction().
Kõigi avatud tehingus tehtud muudatuste tagasivõtmiseks kasutage meetodit Tühista tehing().

Tehingu eraldatuse aste määratakse isolatsioonitasemete järgi. Kõrgeim isoleerituse tase tagab tehingu täieliku sõltumatuse teistest samaaegselt sooritatavatest tehingutest, kuid samaaegsuse aste on samuti oluliselt vähenenud – teised tehingud peavad ootama ligipääsu jooksvas tehingus kasutatavatele ressurssidele. Madalaim isolatsioonitase on vastupidine: see tagab maksimaalse paralleeltöö, mis toob kaasa teiste tehingute olulise mõju praegusele tehingule ja samaaegsusprobleemide ilmnemisele. Mitme kasutajaga süsteemides tuleb teha kompromiss samaaegsuse (samaaegne juurdepääs ressurssidele) ja tehingute eraldatuse tasemete vahel. SQL-keelestandard määratleb isolatsioonitasemed, mis määramisel hoiavad ära konkreetsed samaaegsusprobleemid.

Samaaegsusprobleemid

Tehingute paralleelsel sooritamisel võivad tekkida järgmised probleemid:
- kadunud värskendus(ingl. lost update) - ühe andmeploki samaaegsel muutmisel erinevate tehingutega läheb üks muudatustest kaotsi;
- "räpane" lugemine(eng. dirty read) - tehinguga lisatud või muudetud andmete lugemine, mida hiljem ei kinnitata (tagasi keritakse);
- mittekorduv lugemine(inglise keeles non-repeatable read) - ühe tehingu sees uuesti lugedes osutuvad eelnevalt loetud andmed muudetuks;
- fantoomlugemine(inglise keeles phantom reads) - üks tehing valib selle täitmise ajal samade kriteeriumide järgi mitu rida mitu korda. Teine tehing nende valikute vahel lisab või kustutab ridu, mis kuuluvad esimese tehingu valikukriteeriumidesse ja lõpeb edukalt. Selle tulemusena selgub, et esimese tehingu samad valikud annavad erinevad ridade komplektid.

Vaatleme olukordi, kus need probleemid võivad tekkida:

Kaotatud värskendus

Räpane lugemine

Kui eelmine probleem ilmneb andmete kirjutamisel, on määrdunud lugemine võimalik, kui üks tehing üritab lugeda andmeid, millega teine ​​samaaegne tehing töötab.
Oletame, et erinevad rakendused on avanud kaks tehingut, milles käivitatakse järgmised SQL-laused:

Mittekorduv lugemine

Oletame, et erinevad rakendused on avanud kaks tehingut, milles käivitatakse järgmised SQL-laused:

Tehing 1	2. tehing
	SELECT f2 FROM tbl1 WHERE f1=1;
UPDATE tbl1 SET f2=f2+1 WHERE f1=1;
	SELECT f2 FROM tbl1 WHERE f1=1;

Tehing2-s valitakse välja f2 väärtus, siis Tehing1-s muudetakse välja f2 väärtust. Kui proovite 1. tehingus uuesti väljalt f2 väärtust valida, saate teistsuguse tulemuse. See olukord on eriti vastuvõetamatu, kui andmeid loetakse eesmärgiga neid osaliselt muuta ja andmebaasi tagasi kirjutada.

Fantoomlugemine

Oletame, et erinevad rakendused on avanud kaks tehingut, milles käivitatakse järgmised SQL-laused:

Tehing 1	2. tehing
	SELECT SUM(f2) FROM tbl1;
INSERT INTO tbl1 (f1,f2) VÄÄRTUSED (15,20);
	SELECT SUM(f2) FROM tbl1;

Tehing2 käivitab SQL-lause, mis kasutab kõiki välja f2 väärtusi. Seejärel sisestatakse 1. tehingusse uus rida, mille tulemusel käivitatakse SQL-lause uuesti tehingus 2, et saada erinev tulemus. Seda olukorda nimetatakse fantoomsisestuseks ja see on mittekorduva lugemise erijuht.

Tehingu eraldatuse tasemed

Isolatsioonitase on tehingu omadus, mis määrab tehingu sõltumatuse teistest paralleelselt töötavatest tehingutest.

Standard kehtestab järgmised neli isolatsioonitaset, mille kasutamine hoiab ära teatud samaaegsusprobleemid:
- READ_UNCOMMITTED- fikseerimata lugemine. See isolatsioonitase lahendab "kadunud värskenduse" probleemi, kuid samade päringute jaoks on võimalik saada erinevaid tulemusi, sõltumata tehingu sooritamisest (võimalik, et "määrdunud lugemise" probleem). See on madalaim DBMS-is kasutatav isolatsioonitase ja tagab maksimaalse samaaegsuse.
- READ_COMMITTED- fikseeritud näit. See eraldatuse tase hoiab ära "määrdunud lugemise" probleemi, kuid võimaldab teil saada tehingus samade päringute jaoks erinevaid tulemusi (säilitatakse "mittekorduva lugemise" võimalus);
- REPEATABLE_READ- korduv lugemine. See isolatsioonitase lahendab "mittekorduva lugemise" probleemi. Sellel tasemel on endiselt võimalik täita INSERT-lauseid, mis viivad "fantoomi lisamise" konfliktiolukorrani. See tase on kasulik, kui SQL-lausete täitmist ei mõjuta uute ridade lisamine;
- SERIALISEERITUD- järjestikune täitmine. Kolmas tase. See tase tagab kõigi ülalkirjeldatud samaaegsusprobleemide vältimise, kuid vastavalt sellele täheldatakse samaaegsuse madalaimat astet, kuna tehingute töötlemine (juurdepääsuga samadele ressurssidele) toimub ainult järjestikku.

Paralleelsete tehingute juurdepääsu ja isolatsioonitasemete probleemi lahendust tabeli kujul saab kujutada järgmiselt (“+” - probleem on kõrvaldatud):

Samaaegsusprobleemid ja isolatsioonitasemed	Fantoomlugemine	Mittekorduv lugemine	Räpane lugemine	Kaotatud värskendus
SERIALISEERITUD	+	+	+	+
REPEATABLE_READ	-	+	+	+
READ_COMMITTED	-	-	+	+
READ_UNCOMMITTED	-	-	-	+

SQL-serveri tasemel saate isolatsioonitaseme ise määrata.
kogu sessiooniks, näiteks käskkirjaga
SEADISTADA TEHINGUTE ERALDUSE TASE

konkreetse päringu jaoks, kasutades konstruktsiooni WITH
VALI nimi SERIALISEERITUD lepingutest

Uurige praegusel seansil määratud isolatsioonitaset
valige tehingu_isolatsiooni_tase failist sys.dm_exec_sessions
kus session_id = @@spid

Andmeluku haldamise automaatrežiim (vana režiim, mida kasutati versioonis 8.0) kasutab tehingute isolatsioonitasemeid REPEATABLE_READ Ja SERIALISEERITUD mida pakub andmebaasihaldussüsteem. Need tehingute isolatsioonitasemed tagavad andmete järjepideva ja järjepideva lugemise, ilma et see eeldaks arendajalt täiendavaid lukuhalduse pingutusi.

Hallatud lukustusrežiim (alates versioonist 8.1) võimaldab teil suurendada kasutajate samaaegsust klient-serveri režiimis, kasutades andmebaasi tehingute isolatsiooni madalamat taset ( READ_COMMITTED); vaikimisi on määratud sama isolatsioonitase
ja MS SQL serveris. Andmete kirjutamisel tehingusse lukustavad sisseehitatud keeleobjektid automaatselt vajalikud andmed. Kuid lugemisel on arendajal vaja hallata andmete lukke juhtudel, kui äriloogika nõuab tehingus andmete järjepidevat ja järjepidevat lugemist.

Versiooni 8.3 puhul kasutab hallatud režiim isolatsioonitaset READ_COMMITTED_SNAPSHOT.

järeldused

Tehingud on vajalik DBMS-i mehhanism, mida 1C:Enterprise'is aktiivselt kasutatakse. Samaaegsusprobleemide lahendamiseks saab DBMS-is tehinguid sooritada erineva isolatsioonitasemega.

1C:Enterprise'i kasutatav isolatsioonitase READ_COMMITTED lahendab "Kaotatud värskenduse" ja "Määrdunud lugemise" probleemid: muudetud andmed lukustatakse kuni tehingu lõpuni nii lugemiseks kui muutmiseks (kehtestatud on eksklusiivne lukk).

Isolatsiooni tase READ_COMMITTED ei lahenda probleeme "Mittekorduv lugemine" ja "Fantoomlugemine". Nende probleemide lahendamiseks peate kasutama programmiliselt installitud 1C:Enterprise juhitavaid lukke.

8.3 kasutab paindlikumat isolatsioonitaset READ_COMMITTED_SNAPSHOT.

Igal kliendil on oma korduvad harjumused ja traditsioonid. Olgu see siis lemmikpäev ostlemiseks, toote keskmise maksumuse eelistused või toote lisavõimalused. Kogu see teave aitab meil julgustada klienti teist korda ostu sooritama ja uuelt kasutajalt püsikliendiks liikuma.

Liigume ühekordsetelt ostudelt püsiklientide juurde

Noh, teil õnnestus klient teisendada. See on lahe, aga mis edasi? Statistika järgi teeb 30–80% e-kaubanduse ostjatest kogu oma elutsükli jooksul tellimuse vaid korra. Mängutööstuses teeb 60% klientidest teise tellimuse. Kuidas saame selliste pettumust valmistavate numbritega püsikliente?

See küsimus muretseb turundajad üle kogu maailma. Nad töötavad kõvasti, pannes kõik oma jõupingutused selleks, et muuta kliendid ühekordsetest klientidest püsiklientideks. Olgu selleks siis esmased tellimused jaemüügis või sissemaksed võrgumängudes. Miks on teine ​​järjekord nii oluline? Kui klient teeb oma teise tellimuse või teeb teise sissemakse, suureneb kolmanda tellimuse tegemise tõenäosus kümnekordseks võrreldes klientidega, kes on teinud ainult ühe tellimuse.

Allolev tabel koondab andmed kümnelt juhtivalt e-kaubandusettevõttelt Euroopas ja USAs. Nagu graafikult näha, suureneb järgmise tehingu tegemise tõenäosus jooksvate tehingute arvuga.

Järgmise tehingu tõenäosus sõltuvalt jooksvate tehingute arvust

Paljud ettevõtted koondavad ühekordsed kliendid ühte gruppi ning kasutavad teistsuguse ostu julgustamiseks erinevaid tehnikaid ja sõnumeid. Kõlab nagu hea plaan, eks? Nii või teisiti on kõik grupi kliendid ühekordsed ostjad. Kuid me oleme siin selleks, et arutada teistsugust lähenemist. See teine ​​meetod hõlmab ühekordsete klientide rühma jagamist erinevateks segmentideks, lähtudes nende esimese tehingu omadustest. Sukeldume sügavamale ja kaalume sellise segmenteerimise eeldusi.

Nädalapäev

Alustuseks analüüsime 10 parima ettevõtte korduvostjate käitumist ja püüame aru saada, kas esimese tellimuse päeva ja teise tellimuse päeva vahel on seos. Alustame spordiennustuse analüüsiga. Selles teemas teeb klient sissemakse päeval, mil tema lemmikmeeskonna kõige rohkem matše toimub, tavaliselt laupäeval või pühapäeval. Selliste klientide naasmise ja panuste tegemise tõenäosus on tänapäeval üsna suur.

Kogusime andmeid ja tegime teste ning tulemused olid samad, nagu ootasime. Põhimõtteliselt jäeti teine ​​sissemakse esimesega samale nädalapäevale. Seda on näha ruudu diagonaalil asuvast maksimaalsest tõenäosuse väärtusest.

Teise tehingu tegemise tõenäosus sõltuvalt spordiennustuse esimese tehingu nädalapäevast

Nende kahe tehingu vaheline sõltuvus võib aidata paremini suunata reklaamitegevusi ühekordsete klientide erinevatele rühmadele (sel juhul on meil esimese tehingu päeva alusel 7 rühma) ja meelde tuletada teist tehingut sobivatel päevadel. Huvitavam samm on selle hüpoteesi testimine jaemüügis.

Teise tehingu tegemise tõenäosus sõltuvalt esimese tehingu nädalapäevast jaemüügis

Näeme sarnast olukorda. Kliendid sooritavad oma teise ostu samal nädalapäeval kui esimene. Oluline on märkida, et jaekaubanduses oli dispersioon suurem kui spordikihlvedude valdkonnas. Kuid sõltuvus ise avaldus iga ettevõtte puhul. Kõige populaarsem ostupäev on esmaspäev, kõige vähem populaarne pühapäev. Kui arvestada ainult ühe kaubamärgi tellimuste vahelisi sõltuvusi, saame selle.

Teise tehingu tegemise tõenäosus sõltuvalt ühe kaubamärgi esimese jaemüügitehingu nädalapäevast

Meil on spordiennustuses sellisele käitumisele lihtne seletus, kuid miks me näeme seda tulemust jaemüügis? Põhjus võib olla selles, et ostjate elus on teatud mustrid. Käid neljapäeviti ja reedeti jõusaalis, nädalavahetusel oled perega koos, jääd esmaspäeviti hiljaks tööle ja kohtud reedeti sõpradega. Ostumuster ei tundu kõiki teisi arvestades imelik.

Kellaajad

Nagu võis arvata, testisime sarnaseid hüpoteese kellaaja kohta. Kas esimese tellimuse kellaaja ja teise kellaaja vahel on seos, kui teine ​​tellimus tehti vähemalt seitse päeva hiljem? Jagasime päeva 4 perioodiks: öö, hommik, õhtu ja pärastlõuna – ning kontrollisime iga ajaperioodi teise tellimuste jaotust 6 kaubamärgi puhul.

Teise tellimuse tõenäosus sõltuvalt esimese tellimuse kellaajast

Seos esimese ja teise järjekorra vahel kellaaja järgi tundub ilmne. Kliendid, kes tellivad esimest korda hilisõhtul, teevad tõenäoliselt samal ajal teise tellimuse.

Kauba maksumus tellimuses

Turundajatena püüame suurendada tellitavate kaupade arvu. Edasimüük on turundusmaailmas elustiil ja kui ei ole, siis peaks see olema. Kuid kas me peaksime alati proovima toodet edasi müüa? Kas see on parim lahendus kõigile meie klientidele? Analüüsis uurisime, kas teise järjekorra kaupade maksumus võrreldes esimesega tõuseb.

Andmeallikatena kasutatakse erinevaid brände, mistõttu iga kaubamärgi puhul tuvastasime toote väärtusega eraldi segmendid. Tulemuseks oli 6 hinnagruppi.

Teise tellimuse maksumuse tõenäosus sõltuvalt esimese tellimuse maksumusest

Enamik kliente, kelle tellimused esitati madalas hinnaklassis, jäi teises tellimuses samasse vahemikku.

Järeldus

Meie ülaltoodud analüüs näitab, mida saame esimestest tellimustest õppida. Peamine asi, mida peame meeles pidama, on see, et me ei tohiks kõiki ühekordseid kliente ühte gruppi panna. Kliente tasub segmenteerida sõltuvalt nende nädalapäevast ja ostuajast ning tellimuse maksumusest.
Nende meetodite ja sammude kasutamine aitab teil paremini mõista, kuidas suurendada LTV-d ja saada rohkem püsikliente.

1C Expert sertifikaadi ettevalmistamisel tahaksin kahe väga olulise ja globaalse teema - blokeerimise eelõhtul vaadata midagi, ilma milleta ülaltoodud kontseptsioonid on võimatud - DBMS-i tehingut.

Tehing- loogiliselt seotud, jagamatu toimingute jada. Tehingu saab teha kas tervikuna või üldse mitte. Tehingu kinnitamiseks DBMS-is kasutatakse COMMIT-meetodit.

Tehingu tüüpiline näide on raha ülekandmine ühelt kontolt teisele:

1. alustada tehingut;
2. lugeda konto number 123 rahasummat;
3. vähendada kontojääki 123 100 rubla võrra;
4. salvesta kontojääk number 123;
5. lugeda rahasummat kontol number 321;
6. suurendage oma saldot 100 rubla võrra;
7. arvele uus rahasumma kontol 321;
8. tehing sooritada.

Hankige 267 videotundi 1C-s tasuta:

Nagu näeme, kui tehing ei ole täielikult lõpetatud, pole sellel mingit tähendust.

Põhinõuded (ACID) tehingupõhisele DBMS-ile

Üks levinumaid tehingute ja tehingute DBMS-ide nõuete kogumeid on ACID (Atomicity, Consistency, Isolation, Durability) komplekt. Need on omadused, mis peavad igal tehingul olema:

• Aatomilisus— ühtegi tehingut ei tohiks osaliselt kirjendada;
• Järjepidevus- süsteem on enne tehingu algust järjepidevas olekus ja peab jääma ühtsesse olekusse ka pärast tehingu lõpetamist;
• Isolatsioon— tehingu sooritamise ajal ei tohiks paralleelsed tehingud mõjutada selle tulemust;
• Vastupidavus- ebaõnnestumise korral peavad edukalt sooritatud tehinguga tehtud muudatused pärast süsteemi tööle naasmist alles jääma.

Tehingud 1C-s

Tehingud 1C 8.3 ja 8.2 puhul luuakse nii automaatselt kui ka neid kirjeldavad arendajad.

Saate kasutada meetodit TransactionActive(), et teada saada, kas tehing on aktiivne.

Automaattehingu näiteks on dokumendikonteerimise töötlemine, kataloogiüksuse kirjutamine andmebaasi, inforegistri kirjete komplekti kirjutamine jne.