O SQL Server 2005 έχει δύο μηχανισμούς μέσω των οποίων ενημερώνεται ο client για κάτι που έχει συμβεί στον server. O πρώτος είναι τα Query Notifications και ο δεύτερος τα Notification Services. Τα Notification Services δεν υπάρχουν πλέον στον SQL Server 2008 καθώς γενικά δεν έπιασαν ως τεχνολογία, πράγμα περίεργο καθώς μπορείς να κάνεις πολύ ενδιαφέροντα πράγματα. Υποθέτω ότι ο κόσμος δεν πολυκάταλαβε ποτέ πως δουλεύουν. Δεδομένου λοιπόν ότι είναι μια τεχνολογία που πλέον δεν υφίσταται (αν και υποστηρίζεται για τις τρέχουσες υλοποιήσεις) δε νομίζω να την επιλέξει κάποιος ακόμα κι αν προς το παρόν έχει μείνει στον SQL Server 2005 καθώς κάποια στιγμή θα πρέπει εκ των πραγμάτων να κάνει upgrade.

Τώρα, το πρόβλημα είναι το εξής: Στον κόσμο του .NET η πρόσβαση στη βάση γίνεται σύμφωνα με το disconnected μοντέλο, πράγμα που σημαίνει ότι α) το request ξεκινάει από τον client β) ο client παίρνει τα data που χρειάζεται και κατόπιν κόβεται το connection. Ουσιαστικά, ο server δεν μπορεί να αναλάβει την πρωτοβουλία να μιλήσει με τον client (αν και είναι εφικτό κάτι τέτοιο - όπως στο παλιό ADO), εξού και όλες οι polling λύσεις που υπάρχουν. Αυτή η συμπεριφορά, ευθυγραμμίζεται και με το πως δουλεύει ο browser σε συνδυασμό με τον web server. Πάντοτε η κλήση ξεκινά από τον client προς τον server. Πράγμα που τελικά μας οδηγεί στο συμπέρασμα: Αν επιμένεις ότι θες να καλέσεις από τον server τον client, ξεχειλώνεις την τεχνολογία.

Θα μου πεις, "καλά και τα Query Notifications;". Τα Query Notifications ουσιαστικά βασίζονται σε ένα extension στο TDS protocol του SQL Server. To TDS είναι το ειδικό πρωτόκολλο (application layer protocol, βλ. OSI) που επικοινωνεί ο SQL Server με τον εκάστοτε client. Ουσιαστικά το TDS έχει αποκτήσει κάποια επιπρόσθετα attributes τα οποία αν ενεργοποιηθούν δημιουργούν σε χαμηλό επίπεδο έναν διαφανή μηχανισμό polling τον οποίο φυσικά ο χρήστης δεν αντιλαμβάνεται και δεν χρειάζεται να κάνει πολλά για να τον χρησιμοποιήσει. Αν κάνει σωστό setup, τότε automagically ενημερώνεται για το πότε αλλάζουν τα data στον server.

Και τότε γιατί δεν τα χρησιμοποιούμε κατά κόρον, αφού δίνουν τη λύση στο μεγάλο πρόβλημά μας; Γενικά, η φιλοσοφία που έχουν φτιαχθεί τα QN είναι ότι χρησιμοποιούνται για server-side data που δεν αλλάζουν συχνά. Τυπικό σενάριο είναι τα cached data στον web server που χρησιμοποιούνται για lookups, κλπ. Δεν προσφέρονται για client-side data, ειδικά αν αλλάζουν συχνά καθώς για κάθε request για notification χρησιμοποιούνται resources του server. Το guideline λέει ότι αν φτάσεις τους 10 concurrent χρήστες με notification requests, αρχίζουν τα προβλήματα. Κολλήματα, notifications που ποτέ δεν φτάνουν ή που φτάνουν καθυστεριμένα, κλπ. Πρακτικά, μπορώ να το επιβεβαιώσω καθώς αντιμετώπισα το πρόβλημα σε λύση που είχα υλοποιήσει. Μάλιστα, το πρόβλημα γίνονταν έντονο ήδη στους 7 χρήστες όταν αυτοί συνδέονταν με wireless. Υποθέτω ότι ήταν δικτυακό το θέμα ωστόσο δεν το ψάξαμε παραπάνω, το γυρίσαμε σε own-implemented polling με timer που έπαιξε άψογα.

Παρεπιμπτώντος, θέλοντας να επιβεβαιώσω ότι θυμάμαι καλά τα πράγματα, έπεσα πάνω σε αυτό: http://www.patentstorm.us/patents/7318075/description.html Η πατέντα του TDS. Επίσης, εδώ http://msdn.microsoft.com/en-us/library/ms130764.aspx υπάρχουν περισσότερες πληροφορίες για τα QN.

Τέλος, Peri80, το πρόβλημά σου είναι παρόμοιο με αυτό στην κουβέντα εδώ: http://www.dotnetzone.gr/cs/forums/thread/55451.aspx.