From: Gavin_King/Cirrus%<CI...@ci...> - 2002-03-02 04:59:06
|
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?? |