Η ερώτηση είναι απλή (και ελπίζω και η απάντηση):

Εστω οτι έχω COM+ components τα οποία ξεκινούν transactions ή υποστηρίζουν transactions που ξεκίνησαν από πιο "ψηλά".

Αυτές γίνονται enlist στο DTC. Ωραια. Τωρα, αν τα Com+ μου καλούν SQL Server SPs για παράδειγμα, οι οποίες έχουν ΚΑΙ ΑΥΤΕΣ transaction εσωτερικά, αυτές γίνονται κανονικά enlist ή αγνοούνται;

Αν κάνω rollback, για κάποιο λόγο, transaction από SQL Server SP, τι γίνεται με το transaction του COM+ που κάλεσε την SP?

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Εδώ και καιρό ήθελα να γράψω κάτι σε αυτό το forum για να είμαι ό πρώτος και τελικά με πρόλαβες!

cap wrote:

Εστω οτι έχω COM+ components τα οποία ξεκινούν transactions ή υποστηρίζουν transactions που ξεκίνησαν από πιο "ψηλά". Αυτές γίνονται enlist στο DTC. Ωραια. Τωρα, αν τα Com+ μου καλούν SQL Server SPs για παράδειγμα, οι οποίες έχουν ΚΑΙ ΑΥΤΕΣ transaction εσωτερικά, αυτές γίνονται κανονικά enlist ή αγνοούνται; Αν κάνω rollback, για κάποιο λόγο, transaction από SQL Server SP, τι γίνεται με το transaction του COM+ που κάλεσε την SP?

Το transaction που γίνεται μέσα στον SQL Server, γίνεται τοπικά σε αυτόν και δεν γίνεται enlist στο DTC. Θεωρείται έξω από τα boundaries (όρια) του αρχικού transaction. Δεν αγνοήται, το ξέρω ότι γίνεται αλλά δεν με ενδιαφέρει, δεν το καταλαβαίνει καν ότι υπάρχει. Μπορεί το αποτέλεσμα της SP να προκαλέσει ένα σφάλμα που θα αναγκάσει το αντικείμενο που την κάλεσε να κάνει abort, οπότε έχουμε το abort του transaction σε δεύτερο χρόνο.

Αν είναι ανάγκη να υπάρχει μεγαλύτερος έλεγχος, (πχ αν η σύνδεση ήταν αργή και το connection έκανε timeout με τον SQL, το SP προφανώς θα μπορούσε να έχει τρέξει επιτυχημένα και τα δεδομένα να έχουν γίνει COMMIT στην βάση, αλλά το transaction μέσα στα COM+ Services να είχε αποτύχει) θα πρέπει να μεταφερθεί η "λογική" του SP μέσα σε ένα αντικείμενο για να μπορέσει να συμετέχει και αυτό μέσα στο transaction.

Αν κάτι δεν είναι όσο σαφές όσο θα έπρεπε, εδώ είμαστε να το ξαναπούμε!

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

gcapnias wrote:

Εδώ και καιρό ήθελα να γράψω κάτι σε αυτό το forum για να είμαι ό πρώτος και τελικά με πρόλαβες!

Και εγώ ζοριστηκα λίγο αλλά τελικά βρήκα θέμα

 

gcapnias wrote:

Το transaction που γίνεται μέσα στον SQL Server, γίνεται τοπικά σε αυτόν και δεν γίνεται enlist στο DTC. Θεωρείται έξω από τα boundaries (όρια) του αρχικού transaction. Δεν αγνοήται, το ξέρω ότι γίνεται αλλά δεν με ενδιαφέρει, δεν το καταλαβαίνει καν ότι υπάρχει. Μπορεί το αποτέλεσμα της SP να προκαλέσει ένα σφάλμα που θα αναγκάσει το αντικείμενο που την κάλεσε να κάνει abort, οπότε έχουμε το abort του transaction σε δεύτερο χρόνο.

Αν κατάλαβα καλά, ορίζοντας ένα transaction με αυτή τη λογική στον SQL Server, αυτό που γίνεται είναι οτι το ίδιο τρέχει κανονικά, κάνει commit και abort. Απλά το component που το κάλεσε δεν παίρνει χαμπάρι και αν είναι π.χ. autocomplete, ακόμα και να κάνει abort το SQL server transaction το "απ'έξω" κάνει setcomplete.

Αυτό σημαίνει πρακτικά οτι ναι μεν μπορούμε να χρησιμοποιούμε transactions στον SQL Server παρέα με calling COM+ πραγματα παραέξω αλλά μόνο αν στο rollback έχουμε και ένα raiseerror απο κατω για να μην αισθάνεται μόνο του; Η τα μπέρδεψα πολύ;

Η αφορμή της ερώτησης είναι η εξής: Εχω μερικά άτιμα SPs τα οποία καλούνται από com+ (transaction required). Αυτά τα SPs παίζουν με διάφορα updates, κερσορες, αλλά καλούν και άλλα SPs τα οποία ΔΕΝ πετάνε error αν κάτι πάει λαθος. Απλά επιστρέφουν μια αρνητική τιμή και μάλιστα ως result set οχι ως return value. Εγώ θέλω, επειδή θα έχουν γίνει πραματα και θάματα μέχρι να καλεστεί ένα από αυτά τα "εσωτερικά" SPs (στα οποία δεν έχω έλεγχο και δεν μπορώ να τα αλλάξω), οταν επιστρέψει κάτι ζαβό το "εσωτερικό" SP, να κάνω rollback το transaction του εξωτερικού και ταυτόχρονα να πάρει χαμπάρι το COM+ οτι κάτι πήγε ΠΟΛΥ στραβα και να κάνει abort το δικό του transaction.

H ιεραρχία των κλησεων είναι δηλ. COM+ -> SP -> blammenoSP

Οπου blammenoSP αυτό που δεν πετάει errors, επιστρέφει αρνητικές τιμές σαν resultset αν κάτι πάει στραβά. Scalar.

Τωρα αν δεν χρειάζεται transaction και αρκεί ένα RAISERROR για να αντιληφθεί το com+ οτι κάτι πήγε στραβά και να κανει abort το δικό του παραμύθι παίρνοντας στο διάβα του και όλο το χωριό (ο,τι ήταν να κάνει το SP) και αυτό θα ήταν μια λογικη λύση. Απλά κοιτάω να δω ποιά είναι η πιό λογική λύση εκ των δύο.

---

Σωτήρης Φιλιππίδης

DotSee Web Services