Σχεδιάζω μια εφαρμογή όπου θα αποθηκεύονται requests. Οι εξουσιοδοτημένοι χρήστες θα μπορούν να αποδεχτούν ή να απορρίψουν ένα request. Αν ένα request δεν το αποδεχτεί κανείς (αλλάξει δηλαδή ένα bit πεδίο από 0 σε 1) τότε θα πρέπει να απορριφθεί αυτόματα μετά από ένα συγκεκριμένο χροονικό όριο (ας πουμε 15 λεπτά).
Ψάχνοντας το BOL βρήκα την waitfor και σκέφτηκα το εξής σενάριο:
Φτιάχνω ένα sp το οποίο υλοποιεί την απόρριψη
Φτιάχνω έναν trigger on insert το οποίο χρησιμοποιεί την waitfor. Όταν περάσουν τα 15 λεπτά ελέγχει αν το request (έχω το id του από τον inserted) έγινε αποδεκτό και αν δεν έγινε καλεί την sp απόρριψης.

Πώς σας φαίνεται σαν λύση;
Έχετε κάνει κάποια παρόμοια υλοποίηση;
Καμιά άλλη ιδέα;

Στο BOL λέει ότι η waitfor φτιάχνει ένα thread. Υπάρχει λοιπόν περίπτωση να μπουκώσω το server; Πολύ φοβάμαι πως ναι. Πρόκειται να web εφαρμογή και ο sql server είναι 2005 enterprice edition και φυσικά τρέχει και άλλες βάσεις. Περίπου 100 με 200.

Αν φτιάξω CLR trigger και χρησιμοποιήσω την sleep ή τέλοσπάντων περιμένω εκεί θα είναι καλύτερα;

Οποιαδήποτε εμπειρία, βίωμα, διαίσθηση, ενόραση κλπ καλοδεχούμενη
Μάριοσ

Γιατί δεν το κάνεις στο application layer και το κάνεις στο database layer;

---

Dimitris-Ilias Gkanatsios
Developer Evangelist, Microsoft Hellas

My Blog
StudentGuru
Twitter
Facebook

στο web?
θα δουλέψει;
λες;
το έχεις δοκιμάσει;

Ειδικά, αν θα βάλεις WAITFOR σε trigger θα έχεις πρόβλημα. Κάθε INSERT/UPDATE/DELETE συνεπάγεται και ένα transaction, είτε το έχεις ξεκινήσει εσύ, είτε όχι. Σε περίπτωση που δεν το έχεις ξεκινήσει (δηλαδή πρόκειται για implicit transaction), είναι πολύ βραχύβιο και χονδρικά θεωρούμε ότι ζει από την στιγμή που θα γίνει execute η εντολή μέχρι να ολοκληρωθεί το IO operation. Χρησιμεύει δε για λόγους database consistency. Αν θα βάλεις WAITFOR στον INSERT trigger, σημαίνει ότι θα έχεις 15λεπτα transcations! Δηλαδή, 15λεπτα locks, δηλαδή το concurency πάει περίπατο! Άσε που έτσι κι αλλιώς μέχρι να ολοκληρωθεί ο trigger οι χρήστες δεν θα βλέπουν τη νέα εγγραφή που μπήκε για να μπορούν να την κάνουν update (είπαμε, locking). Θα σου πρότεινα να αποφύγεις (το λέω ευγενικά - θα έπρεπε να πω "μην τολμήσεις να ακολουθήσεις") αυτή ή παραπλήσια λογική και να δουλέψεις ως εξής:

Κάνεις την εγγραφή κανονικά μαζί με την χρονική στιγμή που μπήκε το request. O client κάνει poll ανά 15 λεπτά και βλέπει ποιά νέα requests έχουν μπει και ποιά έχουν λήξει. Εναλλακτικά, μπορείς να βάλεις και ένα job στον server να "καθαρίζει" τα requests που δεν έχει αποδεχθεί κανένας. Όλα αυτά μπορείς να τα συνδυάσεις με κάποιο πεδίο status που θα εκμεταλλευτείς δεόντως. Επιπρόσθετα, στον 2005 μπορείς να χρησιμοποιήσεις notification services αλλά δεν ξέρω πώς παίζουν σε web application λογική. Αυτές είναι μερικές ιδέες που μου έρχονται πρόχειρα. Το τι ακριβώς θα κάνεις εξαρτάται από το business logic της εφαρμογής σου.

 

---

Vir prudens non contra ventum mingit

Χωρίς να είμαι ειδήμονας πιστεύω θα έχεις αρκετά προβλήματα, γιατί απ ότι ξέρω καθώς θα εκτελείς την sp ο server θα σου κλειδώσει τον πίνακα. Οπόταν δέν θα μπορεί άλλο transaction να διαβάσει. Αυτό φυσσικά μπορείς να το ρυθμίσεις αλλά θα έχεις προβήματα concurrency. Συμφωνώ με τον dt008 να υλοποιηθει σε application level. Φυσικά επιφυλάσσομαι να απαντήσουν και οι ειδικοί στον sql server! Αν είναι βάλε και κανένα κομματάκι κώδικα...

---

Coding at Mediterranean Acoustics

Οπας, ο ειδικός που λέγαμε!!!

---

Coding at Mediterranean Acoustics

KelMan:

"μην τολμήσεις να ακολουθήσεις"

μη ντρέπεσαι, εκφράσου ελεύθερα.
Ότι μπλοκάρει τα Transactions το διάβασα στο BOL αλλά ότι το trigger (το insert μας ενδιαφέρει μόνο e;inai transaction δεν το ήξερα)

KelMan:

Κάνεις την εγγραφή κανονικά μαζί με την χρονική στιγμή που μπήκε το request.

Αυτό γίνεται

KelMan:

O client κάνει poll ανά 15 λεπτά και βλέπει ποιά νέα requests έχουν μπει και ποιά έχουν λήξει.

αυτό σημαίνει ότι δεν θα απορρίπτονται τα request στα 15 λεπτά αλλά "κάπου εκεί γύρω"

KelMan:

Εναλλακτικά, μπορείς να βάλεις και ένα job στον server να "καθαρίζει" τα requests που δεν έχει αποδεχθεί κανένας. Όλα αυτά μπορείς να τα συνδυάσεις με κάποιο πεδίο status που θα εκμεταλλευτείς δεόντως.

για δίνε κανένα link, αυτό ψάχνω

KelMan:

Επιπρόσθετα, στον 2005 μπορείς να χρησιμοποιήσεις notification services αλλά δεν ξέρω πώς παίζουν σε web application λογική.

Δεν υπάρχει πρόβλημα που είναι σε web. Αυτά ασχολούνται μόνο με τη βάση.

KelMan:

Το τι ακριβώς θα κάνεις εξαρτάται από το business logic της εφαρμογής σου.

Προφανώς. Ευχαριστώ για τις ιδέες.

agmarios:

Ότι μπλοκάρει τα Transactions το διάβασα στο BOL αλλά ότι το trigger (το insert μας ενδιαφέρει μόνο e;inai transaction δεν το ήξερα)

Δεν "είναι" transaction, απλά συμπεριλαμβάνεται μέσα στο transaction.

agmarios:

KelMan:

Εναλλακτικά, μπορείς να βάλεις και ένα job στον server να "καθαρίζει" τα requests που δεν έχει αποδεχθεί κανένας. Όλα αυτά μπορείς να τα συνδυάσεις με κάποιο πεδίο status που θα εκμεταλλευτείς δεόντως.

για δίνε κανένα link, αυτό ψάχνω.

Για ποιό πράγμα ακριβώς; To να φτιάξεις το job δεν είναι δύσκολο, δες εδώ: http://msdn2.microsoft.com/en-us/library/ms190268.aspx Το τι θα κάνει το job είναι το θέμα. Υποθέτω κάποιο update statement του τύπου "update πίνακα request, set status = 0 where submittime >= ..."

agmarios:

KelMan:

Επιπρόσθετα, στον 2005 μπορείς να χρησιμοποιήσεις notification services αλλά δεν ξέρω πώς παίζουν σε web application λογική.

Δεν υπάρχει πρόβλημα που είναι σε web. Αυτά ασχολούνται μόνο με τη βάση.

Ρίξε μια ματιά στα samples του SQL Server, έχει ένα που λέγεται ShoppingCart (στην κατηγορία Service Broker) που μπορεί να σου κάνει.

---

Vir prudens non contra ventum mingit

κάποιους εδω μέσα πρέπει να τους βάλω στα credits των εφαρμογών που φτιάχνω

agmarios:

στο web?
θα δουλέψει;
λες;
το έχεις δοκιμάσει;

μια ιδέα που έχω είναι η εξής (μιλώντας για application layer πάντα)

υποθέτω ότι μαζί με το status έχεις και ένα smalldatetime πεδίο που καταγράφει πότε έγινε insert το εκάστοτε record
επίσης υποθέτω ότι έχεις μια .aspx που επισκέπτονται οι authenticated users προκειμένου να κάνουνε reject ή accept ένα record
στο page_load σου, λοιπόν, κάνεις ένα update του τύπου UPDATE table SET Status = 0 WHERE DATEDIFF(minute,datetimeColumn,GETDATE()) > 15
και μετά κάνεις select όλα τα rows με datediff μικρότερο του 15 και status 0, προκειμένου να επιλέξει ο authorized user αν θα κάνει accept ή reject κάποιο.

έχει κάποιο performance hit (προφανώς) αλλά όχι και τόσο τραγικό.

άλλη ιδέα είναι να έχεις ένα windows service με timer που να κάνει αυτή τη δουλειά (αν μπορείς να σηκώσεις κάτι τέτοιο στο server)

αλλά, όπως ανέφερε και ο Kelman, τα πάντα εξαρτώνται από το Business Logic σου

---

Dimitris-Ilias Gkanatsios
Developer Evangelist, Microsoft Hellas

My Blog
StudentGuru
Twitter
Facebook

Pak:

Χωρίς να είμαι ειδήμονας πιστεύω θα έχεις αρκετά προβλήματα, γιατί απ ότι ξέρω καθώς θα εκτελείς την sp ο server θα σου κλειδώσει τον πίνακα. Οπόταν δέν θα μπορεί άλλο transaction να διαβάσει. Αυτό φυσσικά μπορείς να το ρυθμίσεις αλλά θα έχεις προβήματα concurrency.

Αυτά φοβόμουν και έκανα την ερώτηση

Pak:

Συμφωνώ με τον dt008 να υλοποιηθει σε application level.

Να σου πω την αλήθεια ό,τι αφορά μόνο τα data προτιμώ να το βάζω στον sql.

Pak:

Αν είναι βάλε και κανένα κομματάκι κώδικα...

Τι κώδικα να σου βάλω; Ένα stored procedure που κάνει insert παίρνωντας 10 παραμέτρους και ένα typed dataset που καλεί την sp?
Περισσότερο θεωρητικό είναι το πρόβλημα. Να τρέχω κώδικα μετά από ένα insert ξέρω (με triggers). Τώρα ψάχνω και διαβάζω πώς θα τρέξω κώδικα 15 λεπτά μετά το Insert.

Ευχαριστώ πάντως για το ενδιαφέρον.

dt008:

μια ιδέα που έχω είναι η εξής (μιλώντας για application layer πάντα)

υποθέτω ότι μαζί με το status έχεις και ένα smalldatetime πεδίο που καταγράφει πότε έγινε insert το εκάστοτε record
επίσης υποθέτω ότι έχεις μια .aspx που επισκέπτονται οι authenticated users προκειμένου να κάνουνε reject ή accept ένα record
στο page_load σου, λοιπόν, κάνεις ένα update του τύπου UPDATE table SET Status = 0 WHERE DATEDIFF(minute,datetimeColumn,GETDATE()) > 15
και μετά κάνεις select όλα τα rows με datediff μικρότερο του 15 και status 0, προκειμένου να επιλέξει ο authorized user αν θα κάνει accept ή reject κάποιο.

έχει κάποιο performance hit (προφανώς) αλλά όχι και τόσο τραγικό.

Μαντεύεις σωστά. Δυστυχώς όμως δεν μπορώ να βάλω τέτοιον κώδικα στη σελίδα γιατί η καθυστέρηση θα είναι όντως τραγική. Το πλάνο είναι να υπάρχουν εκατοντάδες χρήστες οι οποίοι θα βλέπουν (ο καθένας τα δικά του requests οπότε δεν έχουμε τέτοια μπερδέματα) και η σελίδα θα γίνεται autorefresh κάθε 1-2 λεπτά. Όταν ο πίνακας αποκτήσει πολλές χιλιάδες εγγραφές τα πράγματα θα ζορίσουν. Ο server πρέπει όχι μόνο να εξυπηρετεί και την υπόλοιπη κίνηση της εφαρμογής αλλά τρέχει και πολλές ακόμη βάσεις. (Βέβαια αν αποκτήσει ο πίνακας μεγάλο μέγεθος, ο πελάτης θα τα κονομήσει οπότε θα τον βάλω να πάρει δικό του εξοπλισμό αλλά καλό είναι να κρατάω μικρό καλάθι).

dt008:

άλλη ιδέα είναι να έχεις ένα windows service με timer που να κάνει αυτή τη δουλειά (αν μπορείς να σηκώσεις κάτι τέτοιο στο server)

αλλά, όπως ανέφερε και ο Kelman, τα πάντα εξαρτώνται από το Business Logic σου

Αυτό με τον timer είναι ωραία ιδέα, θα στείλω ένα post στο hosting να δω αν το υποστηρίζουν.
Το business logic μου; Να στο πω δεν έχω πρόβλημα αν το βρει ο πελάτης στο google δεν θα ξεπλέξω εύκολα (και ξέρεις ότι το ριμαδο-google το ψάχνει το dnz πολύ και έχει και πολύ καλό pagerank οπότε θα του βγάλει και μέσα στην πρώτη σελίδα)

Αν το μόνο που χρειάζεσαι είναι να εκτελέσεις κάποιο stored procedure, το να φτιάξεις ένα service δεν διαφέρει από το να φτιάξεις ένα job στον SQL Server το οποίο θα εκτελείται κάθε 15 λεπτά. Η λειτουργικότητα θα είναι η ίδια, ενώ το service θα βγει αρκετά πιο περίπλοκο. Από εκεί και πέρα μπορείς να συνδυάσεις δύο πράγματα. Το job μπορεί να μαρκάρει τις ληγμένες εγγραφές, ενώ το query το οποίο φορτώνει τις εγγραφές για τον κάθε χρήστη θα πρέπει να έχει και ένα Where το οποίο θα αποκλείει τις εγγραφές που έχουν λήξει. Θα πρέπει πάντως να έχεις ένα index στην στήλη των ημερομηνιών για να έχεις καλύτερη απόδοση και να αποφύγεις το κλείδωμα περισσότερων εγγραφών απ' όσες χρειάζεται.

---

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

Επίσης, μερικά άλλα θέματα under consideration για την επιλογή job ή service, όπως:

• Να υπάρχει περίπτωση να αλλάζει το timeout για το πότε θεωρείται ληγμένη μια εγγραφή. Ένα service μπορεί να έχει configuration form το οποίο θα χρησιμοποιεί οποιοσδήποτε έχει δικαιώματα για να αλλάζει το 15 σε κάτι άλλο. Η αντίστοιχη δουλειά, αν γίνει σε job στον SQL Server απαιτεί λίγες περισσότερες γνώσεις από αυτόν που θα "πειράξει" το job.
• Το load του RDBMS vs το load των Windows. H κάθε λύση επιβαρύνει διαφορετικά το σύστημα οπότε ανάλογα τη συνολική αρχιτεκτονική, ενδέχεται κάποια από τις δύο λύσεις να σε συμφέρει περισσότερο.
• Αν δεν έχεις dedicated host για την εφαρμογή σου, δύσκολα θα σε αφήσουν να εγκαταστήσεις δικό σου service, οπότε πας για τη λύση του job ή ρίχνεις μια ματιά εδώ: http://www.codeproject.com/aspnet/ASPNETService.asp Δεν το έχω δοκιμάσει και σίγουρα χρειάζεται καλό έλεγχο.

Θα σου πρότεινα, αν έχεις την ευχέρεια, να δοκιμάσεις και τις δύο λύσεις ώστε αφενός να δεις τι σε συμφέρει καλύτερα και αφετέρου να μπορεί η λύση σου μελλοντικά να προσαρμοστεί σε οποιοδήποτε περιβάλλον.

 

---

Vir prudens non contra ventum mingit