Πάει γέρασα ... έχω ξεχάσει και αυτά που ήξερα. Λοιπόν η περίπτωση είναι απλή. Έχουμε μία απλοϊκή εφαρμογή που διαβάζει και γράφει εγγραφές σε ένα πίνακα. Έχουμε 2 χρήστες που την χειρίζονται σε 2 διαφορετικά pcs. Ο πρώτος κάνει select blabla ... βλέπει τα results και επιλέγει ένα για να το μεταβάλει. Έχει ανοίξει το παραθυράκι που θα δώσει τις νέες τιμές αλλά δεν πατάει ok. Φεύγει από το pc του και πάει ... στην κουζίνα. Ο δεύτερος χρήστης κάνει τα ίδια, αλλά επιλέγει την ίδια εγγραφή και την διαγράφει. Ο πρώτος επιστρέφει, πατάει ok και παίρνει error.
Η λύση που σκέφτηκα είναι :
Εισαγωγή locked_flag σε κάθε εγγραφή.
1. Ο χρήστης επιλέγει οτι θέλει να μεταβάλει μία εγγραφή. Η εφαρμογή ελέγχει το flag.
    α. Αν είναι ok τότε κάνει update το flag σε locked .
    β. Δίνει ένα ενημερωτικό μήνυμα και απλά δείχνει την εγγραφή στον χρήση σε read only mode.
2. Ο χρήστης επιλέγει τι θα κάνει με την εγγραφή
    α. Κάνει τις μεταβολές που θέλει και πατάει ok. Η εφαρμογή κάνει update στο row και κάνει update το flag σε clear.
    β. Κάνει cancel. Η εφαρμογή κάνει update το flag σε clear.
Η λογική αυτή έχει πρόβλημα αν κάτι συμβεί πριν προλάβει η εφαρμογή να κάνει update το flag σε clear.

Η ερώτηση είναι απλή : Με transactions (χωρίς το flag) μπορώ να κλειδώσω την εγγραφή αυτή?

Εγραψα χαζομάρες ...
Στο βήμα 1.α ξεκινάει transaction το οποίο τελιώνει μετά το 2.α με commit ή στο 2.β με rollback.
Και ρωτάω :
Αυτό δεν γίνεται με transactions χωρίς flag?
Αν παίζει flag ο δεύτερος χρήστης θα διαβάσει την τιμή του (flag) όπως ήταν πριν ή μετα το begin transaction?

Τα transactions δεν είναι και τόσο καλή ιδέα... Αν αυτός που πάει στη κουζίνα μετά ξεχάσει να γυρίσει, τι θα γίνει; Θα μείνει η εγγραφή κλειδωμένη; Εξάλλου, τα μεγάλα transactions μειώνουν το scalability της εφαρμογής διότι αυξάνονται τα κλειδώματα.

Ουσιαστικά αυτό που περιγράφεις είναι ένα από τα conflict resolution σενάρια (update μιας εγγραφής που κάποιος άλλος έχει ήδη κάνει update, delete μιας εγγραφής που κάποιος άλλος έχει κάνει update, update μιας εγγραφής που κάποιος άλλος έχει κάνει delete). Γενικά τα conflicts προκύπτουν όταν τα data που βλέπεις και δουλεύεις είναι παροχημένα. Πες μας, μιλάς για εφαρμογή που παίζει με ADO.NET; Χρησιμοποιείς Dataset για να φέρνεις τα data στους clients και κατόπιν καλείς την Update method του Dataset;

Σε αυτήν την περίπτωση δεν χρειάζεται να καταφύγεις σε flags. Το Dataset για κάθε DataRow κρατάει την εικόνα του πως ήταν όταν το διάβασε (Για την ακρίβεια, κρατάει πολλές διαφορετικές εικόνες και μία από αυτές είναι το πως ήταν το record όταν έγινε populate το DataTable). Όταν θα καλέσεις την Update method, θα επιχειρήσει να κάνει update την εγγραφή αλλά δεν θα υπάρχει και θα σου επιστρέψει λάθος. Μπορείς να πιάσεις λοιπόν το λάθος και να κάνεις κάποια ενέργεια ανάλογα με τη λογική της εφαρμογής. Π.χ. να μετατρέψεις το update σε insert με νέες τιμές. Ή να ενημερώσεις αυτόν που πήγε να κάνει το update ότι πλέον η εγγραφή δεν υπάρχει.

[Edit] Για περισσότερες πληροφορίες ψάξε για conflict resolution και concurrency ή ξαναρώτα ό,τι χρειαστείς.

Επίσης, ξέχασα, ένα από τα απαραίτητα URLs για το concurrency http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2Fen%2Ftranscripts%2Fwct050103.asp

---

Vir prudens non contra ventum mingit

Με αφορμή αυτά που κουβεντιάσαμε, έγγραψα ένα σχετικό άρθρο: http://www.dotnetzone.gr/cs/blogs/mkelaiditis/articles/9585.aspx

 

---

Vir prudens non contra ventum mingit