Hi,
some general questions: where does this cache fit in? Is it per
Datastore, per Session, or something else?
What's the intended purpose of the cache? This might sounds like a
trivial question, but I can't tell from the discussion. A lot of it
seems to be heading away from just a lightweight persistence layer.
Scared, PaulS :|
Gavin_King/Cirrus%CI...@ci... wrote:
>
> Alright....ima put my head on the block here. Heres the caching algorithm:
>
>
> When Loading Objects
> ====================
> 1. grab the current timestamp (before-select)
> 2. issue SQL selects
> 3. hydrate objects
> 4. disassemble hydrated objects
> synchronized {
> 5. check that 'before-select' is greater than 'after-update' for that
> instance
> 6. if so, add the disassembled state to the cache
> }
>
> Before Updating or Deleting
> ===========================
> synchronized {
> 1. remove cached object from cache
> 2. mark instance uncacheable, by incrementing counter (update-count)
> }
> 3. issue SQL Update or Delete, with a check for stale state
>
> After Transaction Completion
> ============================
> synchronized {
> 1. decrement 'update-count' for uncacheable instance
> 2. if 'update-count'==0, set 'after-update' to system time
> }
>
> Before A Load by ID
> ===================
> 1. look for cached state in cache
> 2. assemble object from cached state
> 3. call PersistentLifecycle.load(), if necessary
>
> (There is a seperate cache per class, the synchronized blocks
> lock the cache itself.)
>
> Are there bugs in this??
|
