Έχω να λύσω ένα θέμα το οποίο λίγο-πολύ όλοι το έχουμε συναντήσει. Έχω μερικούς αλγορίθμους και κάνουν κάποιους υπολογισμούς και διάφορα τέτοια και στο μεταξύ :

α) επεμβένουν σε μια βάση δεδομένων
β) δημιουργούν/διαγράφουν και μεταφέρουν κάποια αρχεία στο δίσκο.

Για λόγους backward compatibility με συνεργαζόμενα υποσυστήματα δεν μπορώ να αποφύγω κάτι από αυτά.

Το πρόβλημα είναι, όπως εύκολα καταλαβαίνει κανείς, πως μπορούν να διασφαλιστούν τις αρχές του ACID (Atomicity, Consistency, Isolation, and Durability) σε όλη αυτή τη διαδικασία. Για τις εργασίες στη βάση δεδομένων τα πράγματα είναι σχετικά απλά. Ξεκινώντας ένα transaction και κάνοντας rollback/commit θεωρώ ότι είμαι καλυμένος, για τις ανάγκες της συγκεκριμένης περίπτωσης. Τι γίνεται όμως με τη δημιουργία/διαγραφή/μεταφορά/αντικατάσταση αρχείων στο μεταξύ.

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

1. Τα αρχεία που είναι να δημιουργηθούν, δημιουργούνται προσωρινά σε άλλη θέση.
2. Τα αρχεία που είναι να διαγραφούν, μπαίνουν σε ένα collection (τα ονόματά τους).
3. Τα αρχεία που είναι να τροποποιηθούν, αντιγράφονται σε προσωρινή θέση και τροποποιούνται εκεί.

Στο τέλος της διαδιασίας, πριν το "Commit Transaction" στην βάση δεδομένων αντιγράφω τα αρχεία από την προσωρινή θέση στην τελική τους και σβήνω αυτά που υπάρχουν στο collection διαγραφής. Μετά από όλα αυτά εκτελώ και το "Commit Transaction" στην βάση. Για λόγους απλότητας επιβάλω διαγραφή ακόμα και αν τα αρχεία είναι readonly.

Προχωρόντας ένα βήμα πιο περα, σε περίπτωση προβλήματος, μπορώ να κάνω rollback στα αρχεία διαγράφοντας αυτά που δημιούργησα, επαναφέροντας αυτά που έσβησα ή αντικατέστησα (φυσικά θα πρέπει να έχω κρατήσει κάπου όλα αυτά).

Μπορείτε σας παρακαλώ να μου παραθέσετε τις απόψεις σας;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Με ενδιαφέρει κι εμένα το ζήτημα αυτό, καθώς ακολουθώ την ίδια ακριβώς λύση (έχω βάλει κι ακόμα ένα layer, σε περίπτωση που αποτύχει το rollback).

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Αυτό που μπορείς να δοκιμάσεις είναι να κρατάς διάφορες version από τα έγγραφα, βάζοντας στο filename τους ένα timestamp.

Aν όλα πάνε καλά, κάνεις "τρέχον" στη βάση το αρχείο που δημιουργήθηκε από το transaction και αλλάζεις το προηγούμενο με το συγκεκριμένο timestamp που έγινε η αλλαγή. Έτσι δεν θα χρειαστείς αλλαγές και σε τυχόν άλλες εφαρμογές που βλέπουνε το "τρέχον". Επίσης καλό θα είναι να κρατάς τα παλιά για κάθε ενδεχόμενο.

Άν κάτι πάει στραβά, κάνεις "τρέχον" - χωρίς timestamp εκείνο με το timestamp του transaction, αντικαθιστώντας το νέο που απέτυχε.

Έτσι μεταφέρεις το όλο πρόβλημα του rollback στη βάση.

Για να μη γεμίσεις σαβούρα μπορείς να φτιάξεις και ένα scheduled task ή service που να σβήνει τα αρχεία που είναι παλιότερα από πχ 1 εβδομάδα

---

Simple Photography

Όλα αυτά γίνονται μέσα στον SQL σου, ή σε .NET  κώδικα; Κι αν το δεύτερο, σε τί version δουλεύεις;;;  Το λέω γιατί αν είσαι σε 2.0, μπορείς να εκμεταλευτείς το System.Transactions και να κάνεις τις κλάσσεις σου transaction-aware.

Αλλιώς, μπορείς να πάρεις καποιες ιδέες απο τον κύριο εδώ, και να "προσομοιώσεις" transactions, ακόμη και σε 1.1. ( Εύχομαι όμως να χρησιμοποιείς 2.0 :D )

---

Angel
O:]

Ευχαριστώ για τις απαντήσεις. Σε αυτό το πλαίσιο κινούμε γενικά.

Ναι, δουλεύω σε 2.0. Προφανώς μιλάς για distrubuted transactions. Αυτό όμως δεν σημαίνει ότι θα κάνω απλά ένα rollback και θα επαναφέρω τα αρχεία όπως ήταν. Σωστά; Θα πρέπει να εγώ να γράψω τον κώδικα που θα κάνει την επαναφορά. Τα distributed transactions απλά θα κάνουν τον κώδικά μου πιο φιλικό προς το περιβάλλον του (context).

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Ναί, ακριβώς έτσι, δυστυχώς ...

---

Angel
O:]

Εγώ θα το έψαχνα προς την κατεύθυνση του COM+. Το COM+ έχει ένα χαρακτηριστικό που ονομάζεται COM+ Compensating Resource Manager που ουσιαστικά σε βοηθάει ώστε το μόνο που έχεις να κάνεις είναι να ορίσεις το Action και το "Undo action". Χρησιμοποιείται όταν θες να δημιουργήσεις transactions που αποτελούνται από "περίεργα" resources. Περισσότερα εδώ: http://windowssdk.msdn.microsoft.com/en-us/library/ms684168.aspx

 

---

Vir prudens non contra ventum mingit

Ξέχασα να αναφέρω ότι με το COM+ CRM, επιτυγχάνεις το "D" στα ACID properties, πράγμα που δεν είναι εύκολο να κάνεις με άλλον τρόπο και σαφώς δεν σε καλύπτει το σενάριο με το transaction που περιέγραψες. Αν για παράδειγμα χρειαστεί να κάνεις rollback (με την υλοποίηση που προτείνεις) και συμβεί ένα καταστροφικό γεγονός αφού γίνει το rollback στη βάση αλλά  πριν να γίνει το clean-up των αρχείων, τότε όταν θα επανέλθει το σύστημα θα έχεις dirty state καθώς δεν θα υπάρχει τρόπος να διαπιστώσει ότι πρέπει να κάνει το clean-up των αρχείων. To COM+ CRM κρατάει ένα log (που το ονομάζει "durable log") και πριν να κάνει οτιδήποτε κατά το commit ή το rollback καταγράφει εκεί τις ενέργειες που πρόκειται να συμβούν, κάτι δηλαδή σαν το transaction log σε μια βάση, μόνο που καταγράφει τις custom ενέργειες που έχεις ορίσει εσύ και πρόκειται να γίνουν. Έτσι, κατά το recovery, κάνει ανάλογα roll-forward και roll-back.

---

Vir prudens non contra ventum mingit