Παίζοντας τελευταία με Web Services παρατήρησα το εξής. Ήμουνα σε debug μιας function ενός Web Service. Μέσα στη function άνοιγα ένα SQL transaction. Κάποια στιγμή και ενώ είχα ανοίξει το transaction είδα ότι είχα ένα λάθος στον κώδικα και έκανα stop το debug. Περίμενα ότι θα κάνει rollback το transaction μολις σταμάταγε. Το αποτέλεσμα όμως ήταν να μείνει ανοιχτό το transaction. Δοκίμασα να κάνο unload το application από την consola του IIS, τίποτα. Έκανα stop τον IIS πάλι τίποτα. Το transaction έμενε ανοιχτό. Αναγκάστηκα να κάνω kill το proccess στον SQL. Και μου δημιουργήθηκε η εξής απορία. Πότε θα έκλεινε αυτό το "έρμο" transaction? Υπάρχει κίνδυνος να μείνει ανοιχτό αν βγάλει κάποιο error το web service έξω από error handler?

---

There are 10 types of people in this world... Ones that understand binary and the ones that don't.

    Ας περιγράψουμε τί έγινε. Έχεις ανοικτό connection και στο connection έχεις ανοικτό transaction. Σταματάς το debug το οποίο σημαίνει ότι σταματας απότομα την εκτέλεση κάθε κώδικα στο service. Μαζί και τον κώδικα που θα έκλεινε το connection στο server και θα οδηγούσε εμμέσως στο κλείσιμο του transaction. Βλέπεις, η σύνδεση στον SQL Server δεν είναι κάποιο handle σε κάποιο τοπικό αρχείο αλλά σύνδεση με sockets ή pipes σε κάποιο άλλο μηχάνημα, οπότε το λειτουργικό δεν ξέρει τί να κάνει για να την κλείσει. Έτσι, μένει ένα connection ορφανό το οποίο τυγχάνει και να περιέχει ένα ανοικτό transaction. Κακό παιδί!
    Ευτυχώς, το ίδιο το λειτουργικό ελέγχει περιοδικά τις ανοικτές συνδέσεις TCPIP και Named Pipes στέλνοντας ένα keep-alive μήνυμα. Αυτό γίνεται κάθε 2 ώρες για το TCP/IP και κάθε ώρα για τα Named Pipes. Αυτή η ρύθμιση μπορεί να αλλάξει από το registry (KeepAliveTime και SessionKeepAlive αντίστοιχα) και ισχύει για όλες τις εφαρμογές που τρέχουν στο μηχάνημα, όχι μόνο τον SQL Server.
    Αυτά για το DEBUG, το οποίο δεν καλεί destructors. Στην κανονική λειτουργία ένα unhandled exception θα έχει σαν αποτέλεσμα να τερματιστεί το service και να απελευθερωθούν όλα τα resources και να κληθούν και οι destructors κάθε αντικειμένου. Έτσι και το connection θα κλείσει κανονικά οδηγώντας σε rollback του ανοικτού transaction. Συνεπώς, δεν υπάρχει κίνδυνος να μείνει ανοικτό το transaction για μεγάλο διάστημα.
    Δυστυχώς, δεν συμβαίνει το ίδιο αν συμβεί κάποιο άλλο απρόσμενο σφάλμα, π.χ. να βγει το καλώδιο δικτύου κατά λάθος ή να πέσει το switch ή να κολλήσει η κάρτα δικτύου ή ... να κλείσει ο debugger. Στην περίπτωση αυτή τα connections θα κλείσουν πάλι μόνο όταν το λειτουργικό ελέγχει για orphaned sessions.

Για περισσότερες πληροφορίες ψάξε στο MSDN ή Books Online για Orphaned Sessions.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Συμφωνώ ότι δεν είναι normal να κλείνεις τον debugger απότομα. Αλλά γιατί δεν συμβαίνει το ίδιο αν τον κλείσεις σε ένα windows application? Εκεί νομίζω οτί θα τερματίσει κανονικά το connection οπότε θα κάνει και rollback.

---

There are 10 types of people in this world... Ones that understand binary and the ones that don't.

Το connection δεν είναι κάποιο local resource του οποίου την ύπαρξη γνωρίζει το λειτουργικό προκειμένου να το ελευθερώσει όταν τερματιστεί κάποια εφαρμογή. Για να κλείσει το connection στο server θα πρέπει ο client να στείλει ένα μήνυμα στο server ειδοποιώντας ότι κλείνει. Αυτό συμβαίνει όταν καλείται ο destructor του αντικειμένου connection. Τώρα, ο debugger ουσιαστικά αναλαμβάνει τον έλεγχο της εκτέλεσης του κώδικα Όταν σταματήσει ο debugger σταματάει η εκτέλεση κάθε κώδικα, οπότε και δεν εκτελείται κανένας destructor και το connection μένει ορφανό. Το λειτουργικό μπορεί να καταλάβει ποια local handles έμειναν ορφανά (π.χ αρχεία, mutexes κλπ) και να τα κλείσει, αλλά όπως είπαμε το connection δεν ανήκει σε αυτή την κατηγορία. Αν μάλιστα ο debugger είναι ελαφρός χαζός (π.χ. VB6) τα αφήνει ακόμα και αυτά ανοικτά και πρέπει να κλείσει η VB για να ελευθερωθούν (πολύ πλάκα ).
Αντιθέτως, αν η εφαρμογή τερματίσει λόγω unhandled exception θα κλειθούν όλοι οι destructors των αντικειμένων που υπάρχουν στη μνήμη, μεταξύ των οποίων και τα connections.

Μια σημείωση τώρα. Τί γίνεται αν ρίξει exception ο destructor? Απάντηση: Μην τα ρωτάς. Οι destructor δεν πρέπει να ρίχνουν ποτέ exceptions.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Καλά όλα αυτά αλλά ξαναρωτάω εγώ. Γιατί ο debbuger από windows application καλεί τον destructor του connection και ο debugger σε web application δεν το καλεί?
Επίσης πάνω σ'αυτό που είπες για το error λόγω δικτύου ή παρόμοιο, μπορεί να μείνει ανοιχτό το connection επομένως και το transaction? Δηλαδή πες ότι είμαι ο Mister Καταστροφή και την ώρα του transaction εγώ κάνω stop τον Web Server. Θα μείνει ανοιχτό?

---

There are 10 types of people in this world... Ones that understand binary and the ones that don't.

Κοίταξες στο COM+ μήπως έτρεχε κανένα application?  Αν θυμάμαι καλά, κάτι auto-magic γίνεται με τα web applications και τρέχουν σε ένα COM+ Application.  Μήπως πρέπει να σκοτώσεις αυτό το application για να καταλάβει ο SQL Server ότι έχασε τον «πελάτη» του?

---

Patrick

Νομίζω ότι όταν κάνεις unload application από την consola του iis στην ουσία κάνει shutdown τα components στο COM+.

---

There are 10 types of people in this world... Ones that understand binary and the ones that don't.

Καταρχήν, όταν σταματάει ο debugger δεν καλείται πλέον κανένας κώδικας του process, ούτε οι destructors. Το ίδιο το λειτουργικό ελευθερώνει τα system resources του process. Τώρα που το σκέφτομαι όμως, και τα network connections είναι system resources! Κάτι περίεργο συμβαίνει

(... Guru Meditation ...) (... Guru Meditation ...)

Αλλά για ποιό process μιλάμε? Μιλάμε είτε για το process του IIS είτε για τα processes που χρησιμοποιεί το ίδιο το .NET. Εδώ είμαι λίγο έξω από τα νερά μου καθώς δεν ξέρω πως συμπεριφέρεται το .NET όταν είναι hosted κάτω από τον IIS. Οπωσδήποτε, αν δεν κλείσει αυτό το process δεν πρόκειται να κλείσει και το connection.

Σχετικά με τον Mister Καταστροφή, αν κάνεις stop τα processes θα κλείσουν κανονικά. Αν όμως τραβήξεις το καλώδιο από την πρίζα το connection και τα transaction θα μείνουν ανοικτά μέχρι να στείλει ο Windows Server κάποιο keepalive και δει ότι ο client χάθηκε. Η συμπεριφορά αυτή είναι λογική αν σκεφτεί κανείς ότι το κάθε πρωτόκολλο δικτύου πρέπει να αντιμετωπίσει συμφορήσεις, καθυστερήσεις και χαμένα πακέτα. Από την άλλη, δεν θέλεις να υπερφορτωθεί το δίκτυο με keepalive πακέτα.


Μια καλή περιγραφή της συμπεριφοράς των Windows και του SQL Server μπορείτε να βρείτε εδώ http://support.microsoft.com/default.aspx?scid=kb;en-us;137983 Περιλαμβάνει και την περίπτωση που ο χρήστης κλείνει τον υπολογιστή με cold power off

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Κατ'αρχήν κάνεις restart τον IIS ή το worker process?  Νομίζω ότι ένα πιθανό αίτιο του προβλήματος μπορεί να βρίσκεται στο web/machine config  του webserver, μια και σε μερικά πειράματα που έκανα πριν λίγο καιρό είδα ότι το restart του IIS δεν ξαναξεκινάει πάντα το aspnet_wp (μην ρωτάτε γιατί, δεν έχω ιδέα).
Όσο για το σενάριο του Mr. Disaster, η εμπειρία από δικά μου πειράματα σε COM έχει δείξει ότι ναι μπορεί να μείνει ανοιχτό και ναι μπορεί να δημιουργήσει πρόβλημα για ένα μικρό χρονικό διάστημα (το υπέροχο λάθος με το transaction is in firehose mode), αλλά μετά καθαρίζει το σύστημα.

Btw, hello everybody, επιτέλους βρήκα ένα θέμα να κάνω post [<)]

---

The people of the straight land have really got it made, a warm friendly sleep from the craddle to the grave