locked
Commit transaction hibánál néha kell rollback? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Sziasztok!

     

    Egy sp-ben a COMMIT TRANSACTION kapcsán van-e értelme ROLLBACK TRANSACTION-ön gondolkodni?

     

    Ha commitnél elhasal a rendszer, és visszaad egy hibakódot az @@ERROR, akkor nyugodtan hátradőlhetek, vagy gondolkodhatok azon, hogy kiadjak-e egy rollbacket?

    Ha statement abort lép fel aktív tranzakció esetén egy commitnál, akkor a rendszer rollbackkelt-e, vagy sem?

    Ha nem, akkor commit előtt figyeljem a @@TRANCOUNT-ot, és ha 1 volt, majd a commit után nem nulla, akkor kiadjak egy rollbackket?

     

    Az is érdekelne, ha kliensoldalon ADO-val vezérlem a tranzakciót, akkor a connectionön kiadott CommitTrans mit művel, ha elhasal már ott a művelet? Azért odaszól a szerveroldalra, hogy commitálni próbált, de nem sikerült, és a szerver erre meg jól megrollbackkeli?

     

    Wednesday, August 29, 2007 10:06 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    A BOL olvasgatásakor rátaláltam az XACT_STATE-re.

     

    Mivel a hibakezelésnél TRY-CACTH használatát részesízem előnyben, így az XACT_STATE megválaszolta a kérdésemet.

     

    Monday, September 3, 2007 12:25 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

     

    ADO részhez:

    Szabályosan a tárolteljárás belsejében figyelned kellene, hogy inditottak-e felül vlmit kb igy:

     

    Code Snippet

    CREATE PROC tt

    AS

    DECLARE @TC int

    SET @TC = @@trancount

    IF @TC = 0

    BEGIN TRAN

     

    BEGIN TRY

    --művelet

    if @TC = 0

    COMMIT TRAN

    END TRY

    BEGIN CATCH

    if @TC = 0

    ROLLBACK TRAN

    END CATCH

    return

     

     

     

    ELvileg, ha kiadtál egy commitet, akkor a kliens oldalinak el kellene hasalnia, mert nincs már aktív tranzakció.

    Wednesday, August 29, 2007 12:16 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello,

     

    szerintem ha ADO-t használsz is - egyértelműen el kell döntened, hogy hol akarod a tranzakciót kezelni:

    - Ha "vastagabb" logikai réteget húzol tárolt eljárásokból és csak hívogatod őket ADo-val, akkor kezeld ott a tranzakciót, ahogy Safi is írta

    - Ha az ADO réteg hordozza az üzleti logika nagyobb részét, akkor kezeld ott a tranzakciókat.

    Amit mindenképp el kellene kerülni, hogy mindkét oldalon véletlenül se kezelj tranzakciót.

    Egyébként ha ADO-t használsz, érdemes a következő pattern-ben gondolkodnod:

    - Egyáltalán nem kezelsz hibát SQL oldalon, ha hiba van, az sql úgyis dobni fogja a .net keretrendszer felé - ott elkapod, kezeled a hibát, tranzakciót, stb. Sokkal rugalmasabb és gyorsabb, nem kell félni tőle. De ha neked szimpatikusabb az SQL, vagy könnyebben boldogulsz vele - tedd oda a hiba és tranzakciókezelést. Tényleg csak ízlés kérdése.

     

    Ha az SQL-es réteged lesz erősebb, kicsit kevésbé lesz rugalmas az alkalmazásod - szerintem érdemes használni az ADO-ban rejlő képességeket és vékonyabb SQL réteget építeni. (Ez csak a magánvéleményem)

    Ajánlanám a DataAccess Application block-ot:

    http://msdn2.microsoft.com/en-us/library/ms954827.aspx

     

    Thursday, August 30, 2007 7:11 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Szia!

     

    Lehet, hogy nem voltak a kérdéseim világosak, mert egyáltalán nem a kérdésekre válaszoltál!

     

    Az sp-s kérdés az volt, hogy előfordulhat-e olyan helyzet, hogy egy COMMIT-nál keletkező hiba esetén statement abort áll elő, és a @@TRANCOUNT 1-en marad.

    Ha statement abort lép fel aktív tranzakció esetén egy commitnál, akkor a rendszer rollbackkelt-e, vagy sem?

     

    Az ADO-s kérdés arra keresi a választ, hogy egy félbeszakadt CommitTrans, ami a kliensoldalon szakad félbe, takarít-e maga után? Tehát, ha CommitTrans után hibát jelez vissza a rendszer, akkor a tranzakciót valaki abortálta-e vagy sem. (Ez a kérdés csak elméleti, az sp-s kérdés kapcsán merült fel.)

     

    A kliensoldalon szakad félbe szerintem még mindig sokak számára félre érthető. Ezt értem alatta: a végrehajtás szála el sem jut az SQL szerverhez, tehát pl. az ADO-t megvalósító, kliens oldalon lévő kódon belül állt elő valami hiba, amire a vezérlés visszakerült a VB6 kódba, egy hibajelzés kíséretében.

     

     

    Tehát nem az a kérdés számomra, hogy ki kezelje a tranzakciókat, mikor indítson stb.

     

    Amúgy a kliensoldali kolbászolást nagyon gáznak tartom! Félek is tőle nagyon!  

    Ezt jobbára hazánk clipperen nevelkedett fiai művelik. Rugalmasan és gyorsan rángatnak át adatokat, nagyon ízlésesen.

     

    SzL
    Thursday, August 30, 2007 9:10 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    A BOL olvasgatásakor rátaláltam az XACT_STATE-re.

     

    Mivel a hibakezelésnél TRY-CACTH használatát részesízem előnyben, így az XACT_STATE megválaszolta a kérdésemet.

     

    Monday, September 3, 2007 12:25 PM