Design & Architecture

Απ: ACID και Διαχείριση Αρχείων

KelMan — Tue, 10 Oct 2006 21:46:50 GMT

Ξέχασα να αναφέρω ότι με το 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.

Απ: ACID και Διαχείριση Αρχείων

KelMan — Tue, 10 Oct 2006 08:24:44 GMT

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

Απ: ACID και Διαχείριση Αρχείων

anjelinio — Tue, 10 Oct 2006 07:18:38 GMT

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

Απ: ACID και Διαχείριση Αρχείων

Dimitris Papadimitriou — Tue, 10 Oct 2006 06:10:43 GMT

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

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

Απ: ACID και Διαχείριση Αρχείων

anjelinio — Tue, 10 Oct 2006 04:18:14 GMT

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

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

Απ: ACID και Διαχείριση Αρχείων

dimkasta — Tue, 10 Oct 2006 03:45:51 GMT

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

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

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

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

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

Απ: ACID και Διαχείριση Αρχείων

Mitsaras — Tue, 10 Oct 2006 00:53:17 GMT

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

ACID και Διαχείριση Αρχείων

Dimitris Papadimitriou — Tue, 10 Oct 2006 00:37:53 GMT

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

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

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

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

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

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

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

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

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