Δουλεύω με το caching application block και βλέπω ότι μπορεί να αρχίσει να πετάει μόνο του αντικείμενα από το cache όταν ο αριθμός τους ξεπεράσει κάποιο όριο (χρησιμοποιούν τον όρο scavenging). Επειδή όμως έχω μια περίπτωση που μέσα στο cache θα βάλω ολόκληρα datasets, αυτό που με εδιαφέρει είναι όχι ο αριθμός τους (ο οποίος θα είναι μικρός σε σχέση με το τυπικό 1000 που έχει default όριο) αλλά το συνολικό μέγεθος της μνήμης που θα καταλαμβάνει το cache (πρόκειται για in-memory cache). Απ' ότι είδα, στην ουσία το cache το κρατάει σε ένα hashtable το οποίο βεβαίως έχει έτοιμο το count.

Αυτό που ψάχνω είναι ένας τρόπος να ελέγξω το συνολικό μέγεθος του cache αλλά και κάθε αντικειμένου ξεχωριστά. Διαβάζω όμως το εξής:

Normally you cannot get the size of an object in the managed heap. This is because that size doesn't make sense in the managed world due to different reasons. One of them could be that the size of the same object is not guaranteed to be the same between two starts of the application. The JIT compiler is free to layout the objects as it sees fit. The layouting can be different due to different configuration of the machine, different version of the CLR, etc.

Furthermore, your type may reference other reference types. Even two objects can cross-reference the same object. How can you possibly tell what is the size of the object.

(Rune Andersen, http://www.dotnet247.com/247reference/msgs/45/226612.aspx)

Θα ήθελα τις απόψεις σας, τόσο για τις πιθανές λύσεις στο πρόβλημά μου, όσο και για τη λειτουργικότητα που θα είχε να έχεις scavenging με βάση το size. Ίσως κάτι τέτοιο θα έπρεπε να προστεθεί στο application block.

PS. salvage, scavenge (collect discarded or refused material) "She scavenged the garbage cans for food"

Επανέρχομαι για να περιγράψω καλύτερα το σενάριό μου:

Έχω φέρει κάποια δεδομένα στον client. Όταν ο client τα χρησιμοποιεί, τα κρατάω στη μνήμη. Μεταξύ των sessions τα κρατάω στο δίσκο. Οι μόνοι λόγοι για να βγάλω δεδομένα από τα cache είναι:

1. Να έχει πρόβλημα ο client με τη μνήμη του (να μην χωράει όλα τα cachaρισμένα αντικείμενα), οπότε βγάζω περιττά δεδομένα από τη μνήμη (παραμένουν όμως στο δίσκο).
2. Κάποιο από τα δεδομένα να είναι invalid, οπότε σε αυτή την περίπτωση το αφαιρώ και από τη μνήμη και από το δίσκο.

Ας εξετάσω το θέμα από πλευράς caching application block (CAB):

Τι expiration policies πρέπει να έχω; Πότε λήγει δηλαδή ένα αντικείμενο του cache; Λήγει μόνο όταν κάτι αλλάξει στη βάση. Και επειδή το να ρωτάμε τη βάση "Πες μου καλή μου, πότε άλλαξε το x αντικείμενο τελευταία φορά" είναι λίγο ακριβό, η ερώτηση αυτή θα γίνεται στις εξής περιπτώσεις:

1. Αν ο client ζητήσει το δεδομένο, και έχει περάσει επαρκές χρονικό διάστημα από την ώρα που ρωτήσαμε για τελευταία φορά.
2. Αν θέλουμε να προφυλάξουμε τον client από την αναμονή της ερώτησης, ίσως να ρωτάμε από μόνοι μας σε αραιά διαστήματα.

Εκτός από το δεύτερο, που ακολουθεί το μοντέλο του CAB (κάποιος κάθεται από πίσω και ρωτάει μόνος του), το πρώτο δεν ταιριάζει με τον τρόπο που είναι στημένα τα expiration policies (Είναι expiration policy με την ευρύτερη έννοια, αλλά δεν είναι όπως είναι η δομή του CAB).

Συνοψίζοντας λοιπόν, μαζί με το πρώτο post, για να δουλέψει για την περίπτωσή μου το CAB, χρειάζεται να κάνω τα εξής:

1. Να επεκτείνω τον cache manager ώστε να μου δίνει με κάποιον τρόπο το μέγεθος των δεδομένων που έχω στη μνήμη, έστω και κατά προσέγγιση. Ίσως παρακολουθώντας κάποιον performance counter, ίσως βρίσκοντας κάποια πατένα για τα συγκεκριμένα δεδομένα που παίζω (datasets).
2. Να επεκτείνω τον cache manager ώστε να ελέγχει για invalid δεδομένα πριν τα επιστρέψει με την απλή διαδικασία: Ρωτάω τη βάση αν άλλαξε (αν χρειάζεται να ρωτήσω) και αν άλλαξε ζητάω να πάρω φρέσκα δεδομένα.

Αυτά τα posts στην ουσία τα γράφω για να βάλω σε μια σειρά τις σκέψεις μου, μήπως και βγάλω άκρη. Αλλά μια που τα διαβάζεις κι εσύ, θα εκτιμούσα οποιοδήποτε σχόλιο... Απάντησέ μου για παράδειγμα στην ερώτηση: "Είναι τόσο ασυνήθιστο το σενάριο που περιγράφω;". Περιέργως πως, όλα μέσα στο CAB έχουν σκεφτεί και docuμεντάρει για να γίνονται extend, τον cache manager όμως όχι και τόσο...