Antallet af rækker i DB2 tabellerne bare stiger og stiger. Den tid, de skal være tilgængelige i, stiger også. Faktisk er der mange stedet 24 timers drift alle ugens 7 dage. Antallet af samtidige brugere på DB2 systemerne stiger også. Alt dette gør det svært at foretage større ændringer af indholdet af DB2 tabellerne. Derfor har rigtig mange også lært at lave programmer, der kan committe med jævne mellemrum, så de låse DB2 tager, hurtigt kan blive frigivet igen.

For at kunne committe med jævne mellemrum benyttes oftest en tæller i programmet, der laver mange opdateringer. Når tælleren når en bestemt værdi, så committes der. Denne fremgangsmåde er let at kode og forstå, men den har den klare ulempe, at nogen gange tager det kort tid for tælleren at opnå den ønskede commitværdi, mens det andre gange tager lang tid, og det endda i samme eksekvering af programmet. Derfor har nogen installationer også indført, at man i stedet skal styre sin commit på tid. I dette tip vil jeg gennemgå en nem metode til at styre commit på tid.

Første trin er at få fat på, hvad klokken er. Det kan gøres ved at bruge current timestamp. Problemet er bare, at hvis du bruger current timesamp fra den centrale cursor i dit program, så vil den have samme værdi for alle rækker. Du kan i stedet bruge udtrykket TIMESTAMP(GENERATE_UNIQUE()), som også returnerer et timestamp, men et nyt friskt et for hver ny række, du fetch'er.

Andet trin er at bestemme, hvornår der skal committes næste gang. Her kan du i starten af programmet og efter hver commit benytte en SET :nextCommitAt = current timestamp + :commitSeconds SECONDS. Hostvariablen commitSeconds skal indeholde det antal sekunder, der skal gå inden næste commit skal foretages. Jeg vil anbefale, at du erklærer denne variabel som en PIC S9(4) BINARY i COBOL og som FIXED BIN(15) i PL/I. Hvis du bruger et andet programmeringssprog, så skal erklæringen svare til en SMALLINT i DB2.

Hver gang du har behandlet en række kan du nu sammenligne hostvariablen, der indeholder timestampet lavet med GENERATE_UNIQUE, med nextCommitAt og når nextCommitAt indeholder den mindste værdi, er det blevet tid til at foretage en commit. Det interessante er, hvad du skal sætte commitSeconds til. I DB2 version 8 og fremefter undersøger DB2, om der er opstået en deadlock hver femte sekund eller hurtigere. Default er hver femte sekund. Hvis du vil undgå deadlocks er det altså en rigtig god ide at sætte commitSeconds til 5 eller mindre. Du kan eventuelt spørge en DBA eller en DB2 systemprogrammør, hvor tit DB2 holder øje med deadlocks på din installation, så du sætter commitSeconds i overensstemmelse med denne værdi. Du kan godt eksperimentere med at sætte commitSeconds højre end 5, men risikoen for at skabe problemer for dit program og for andre stiger ved at gøre det. Og så er de nyeste mainframe CPU'er ekstremt hurtige, så de kan nå rigtig meget på fem sekunder.