Re: [Hibernate-devel] caching algorithm

[Paul S. <pau...@ne...>]

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??