Rekuperi ŝarĝon de SQL Server al Oracle post kiam la VPN falis

Transigo inter datumbazoj mortas kiam la VPN falas, kaj «ruligu ĝin denove» ne estas rekupera plano. La eltiro el la fonto povas esti kompleta, la celo povas jam esti farinta commit, aŭ la respondo simple perdiĝis sur la revena vojo. Tiuj tri statoj bezonas malsamajn agojn, kaj kliento kiu konas nur «eraro» ne povas distingi ilin.

La solvo estas arkitektura: donu al ĉiu rulo daŭran lotan identecon, kaj lasu la datumbazojn respondi demandojn anstataŭ lasi la klienton diveni.

Kion la datumbazo efektive garantias

SQL Server kaj Oracle ambaŭ donas atomecon ene de transakcio. Nek unu donas al vi atomecon trans ambaŭ. Perdita konekto ne difektas la datumbazon, kaj ĝi ankaŭ ne trudas manan malfaron, ĉar la servilo solvas sian propran transakcion sen vi. Kio rompiĝas estas la sciado de la alvokanto pri la rezulto.

Aparte commitita signifas aparte commitita. VPN portanta ambaŭ konektojn ne kunfandas du commit-ojn en unu laborunuo.

La commit pri kiu vi neniam aŭdis

Unu malsukcesa reĝimo punas naivan relanĉan logikon: la servilo commitas, kaj la konfirmo neniam atingas la alvokanton. Oracle dokumentas tion kiel la problemon de nekonata rezulto kaj provizas Transaction Guard por ĝi en la transakcia dokumentaro. Komunika eraro ne estas pruvo ke sendita commit malsukcesis, kaj trakti ĝin kiel pruvon estas kiel loto afiŝiĝas dufoje. La distingo plej gravas sur la relanĉa vojo, kie la operatoro havas eraran mesaĝon kaj neniun alian signalon por agi.

Do la rekupera paŝo devas legi la rezulton el la celo anstataŭ dedukti ĝin el la erara teksto.

Donu al la transigo lotan identecon

Ĉiu rulo ricevas neŝanĝeblan lotan ID, kaj la celo registras kion ĝi faris kun tiu ID. La vivociklo havas kvar paŝojn, kaj ĝi aspektas same sendepende de la vendisto:

1. Eltiru identigitan, neŝanĝeblan fontan loton kun registrita skemo kaj limo.
2. Transigu ĝin al la prepara areo de la celo kaj detektu nekompletan aŭ kontraŭdiran enhavon antaŭ ol deklari ĝin preta.
3. Apliku ĝin laŭ la propraj unikecaj aŭ ŝlosaj reguloj de la celo kaj registru la finiĝon en la sama loka transakcio.
4. Kongruigu la daŭran rezulton per la subtenata protokolo antaŭ konfirmo aŭ relanĉo.

Relanĉoj reuzas la ID. Nova ID por ĉiu provo subfosas la duplikatan preventadon kiun vi ĵus konstruis, kio ŝajnas evidenta ĝis relanĉa envolvilo aŭtomate generas unu.

La ID ankaŭ donas al vi ion kontraŭ kio kongruigi poste, longe post kiam la klienta procezo foriris.

Postulu la loton, tiam apliku

La aplika paŝo devas postuli la lotan ID, fari la komercajn ŝanĝojn, kaj registri la finiĝon en unu loka transakcio. Fari la kontrolon kaj la enmeton kiel apartajn ordonojn reenkondukas la vetkuron kiun vi provis forigi. Se du laborantoj vetkuras, ĝuste unu postulo venkas kaj la alia estas informita.

Mankanta finregistro ne estas pruvo ke okazanta transakcio neniam commitos. La postulo devas serialigi konkurantajn provojn, aŭ la protokolo devas legi la daŭran rezulton antaŭ ol decidi ion ajn.

Uzu la subtenatan mekanismon de la datumbazo por tiu serialigo anstataŭ kontrolu-kaj-ripetu buklon en la aplika kodo.

Kion la dezajno ankoraŭ ne povas promesi

Preparo faras la laboron relanĉebla kaj malpliigas dependecon de unu longdaŭra seanco. Ĝi ne kreas ununuran atoman commit trans SQL Server, Oracle kaj ajna ekstera flanksigno kiun la laboro plenumas. Se la komerco vere bezonas tion, dezajnu kaj kvalifiku subtenatan distribuitan transakcion aŭ kongruigan procezon, inkluzive de kiu posedas dubindan laboron. Io ajn pli malforta ol tio apartenas al kongruiga runlibro, ne al la transiga kodo.

Akceptu interrompon en tri lokoj: dum transigo, dum apliko, kaj post commit sed antaŭ konfirmo. Poste kontrolu la komercan rezulton anstataŭ la mesaĝon de la kliento, kaj lasu la lotan ledgeron diri ĉu la laboro estas nekompleta, commitita, aŭ ankoraŭ nesolvita.