MySQL: Har jeg glemt å kjøre commit?

[quantum]

Ellers får man jo til akkurat det samme med savepoints (trur eg), så jeg ser heller ikke problemet. Men fant en posting på et forum som antyda at det opprettes en connection til i sånne tilfeller.

Savepoints kan ikke brukes til å emulere flere transaksjoner, det brukes til avansert feilhåndtering...

 

 

For å sitere wikipedia-kilden din:

 

A savepoint is a way of implementing subtransactions (also known as nested transactions) ...

 

Men, det spørs vel om det funker helt på samme måte som nestede transaksjoner mht. isolation, og det er vel da sikkert årsaken til at man ikke bruker savepoints, men oppretter ny connection ifm REQUIRES_NEW.

[quantum]

Hvis du har en transaksjon A som henter ut data fra databasen. Disse dataene skal så prosessesres og en endringslogg skrives tilbake, med en transaksjon pr objekt. La oss si at hvert objekt er en bil. Du er mao interessert i å vite hvor mange deler som er brukt før du er ferdig med å gjøre ferdig alle bilene. Du bruker derfor en transaksjon pr bil.

 

Med nested transaksjoner/savepoints vil du ikke ved Serializable transaksjonsnivået se hva som skjer i hver nested transaksjon/savepoint utenfor denne nestede transaksjonen. Når du så prøver å lage et bestillingsforslag i en helt annen transaksjon ser det mao ikke ut som du har brukt noen deler, for bil nr 10.000 som er den siste i batchen er ikke ferdig.

 

Må også innrømme at jeg ikke forstår poenget ditt her, pointet med en transaksjon, nestet eller ikke - må jo være 1) å evt. få rulla tilbake transaksjonen som en «enhet», og 2) gitt et isolation-level: å skjule (eller ikke - avh. av isolation) for andre transaksjoner det arbeidet som holder på å gjøres i den gitte transaksjonen.

 

Du tar et scenarie hvor en gitt transaksjons/isolation-konstellasjon ikke egner seg og så generaliserer du og sier at det ikke egner seg i alle andre sammenhenger heller.

 

La oss si vi har tre transaksjoner da t1, t2 og t3. t2 er nestet inni t1. t3 foregår parallellt som en selvstendig transaksjon, og vi kjører i et gitt isolation-level. t3 kan vel da i like liten (eller stor) grad se hva som skjer inni t2 som i t1? blir det ikke helt irrelevant for t3 om t2 i det heletatt eksisterer, eller om alt arbeidet foregår «flatt» i t1 isteden?

 

Nå kan jo transaksjoner kjøre med ulike isolation-levels, og jeg antar nestede transaksjoner kan ha annet isolation-level enn den omsluttende, og dét tror jeg nok ikke man kan «simulere» med savepoints, de kjører i samme level som transaksjonen de eksisterer i.

[blackbrrd]

Poenget mitt er at av og til så vil du lagre data som ikke kan være avhengig av at den gjeldende transaksjonen committes. Man oppretter da en ny transaksjon for disse dataene og lagrer disse.

 

I EJB3-sammenheng vil man annotere en slik metode med REQUIRES_NEW.

 

Et eksempel vi har ser omtrent slik ut:

Transaksjon A Start

Transaksjon B1 start - slutt

Transaksjon B2 start - slutt

...

Transaksjon BN start - slutt

Transaksjon A Slutt

 

Transaksjon A blir startet i en metode X, som igjen kaller en metode Y som starter transaksjon B1..N

[quantum]

Poenget mitt er at av og til så vil du lagre data som ikke kan være avhengig av at den gjeldende transaksjonen committes. Man oppretter da en ny transaksjon for disse dataene og lagrer disse.

 

I EJB3-sammenheng vil man annotere en slik metode med REQUIRES_NEW.

 

Et eksempel vi har ser omtrent slik ut:

Transaksjon A Start

Transaksjon B1 start - slutt

Transaksjon B2 start - slutt

...

Transaksjon BN start - slutt

Transaksjon A Slutt

 

Transaksjon A blir startet i en metode X, som igjen kaller en metode Y som starter transaksjon B1..N

 

Og hvis B1-N er nestet inni A, så vil de likevel være committed selv om A rulles tilbake, på samme måte som om de hadde kjørt utenfor A (og A var suspended), i motsetning til hva som ville skjedd hvis man simulerte dette med savepoints? Tenker da i ren SQL-kontekst, ikke nødvendigvis EJB.

 

Men vet du hvordan det ligger an mht. isolation? Kan BN se hva som er gjort i A før A er committed når de kjører som nestede transaksjoner? Blir det noe annerledes enn om de hadde kjørt utenfor A (som de gjør i en EJB-REQUIRES_NEW-sammenheng), i et gitt isolation-level?

[blackbrrd]

Nested transactions generellt:

http://en.wikipedia.org/wiki/Nested_transaction

 

EJB:

"4. Does the J2EE platform support nested transactions?

No, the J2EE platform supports only flat transactions. "

http://java.sun.com/blueprints/qanda/trans...ment/index.html

 

Mitt syn på nested transactions er: hvorfor gjøre det?

Endret 7. desember 2009 av blackbrrd

[quantum]

Mitt syn på nested transactions er: hvorfor gjøre det?

Nei, det måtte jo være hvis det løser det man ønsker å oppnå det da ... det er jo ikke akkurat vanskelig å se at det kan gjøre visse ting litt enklere å kode, gitt en «passelig» implementasjon av nestede transaksjoner. Men det er kanksje værre å finne en database som faktisk støtter det, eller to som implementerer det funksjonelt likt ... og da blir vel igrunnen min konklusjon den samme som din.