Before I start asking dumb questions, let me reword what I think you're saying to make sure I understand.
At the point a collection is loaded from the database, Hibernate should disassemble each object in the collection and store that either with the collection's owner's cached value or in a cache in the collection's CollectionPersistor. Is that correct? Thanks, John -----Original Message----- From: Gavin_King/[EMAIL PROTECTED] [mailto:Gavin_King/[EMAIL PROTECTED] Sent: Thursday, August 01, 2002 11:13 AM To: Urberg, John Cc: [EMAIL PROTECTED] Subject: RE: [Hibernate-devel] Getting Collections to pull data from the c ache >Well that answers my question. Maybe Gavin can give me a quick >overview of what's involved before I volunteer. :) Caching for entities is implemented in cirrus.hibernate.impl.ClassPersister which delegates through to cirrus.hibernate.cache.CacheConcurrencyStrategy Each instance of ClassPersister maintains its own cache of instances of its own particular *subclass*. Objects are cached in a "disassembled" state. This means: (1) primitives -> java.lang wrappers (2) other immutable types -> unchanged (3) mutable types -> copied (4) collections -> the id (5) association -> the id (6) components -> arrays of properties (7) entity -> an array of properties To actually enable caching of a collection, we would have to change (4) to: (4) collections -> arrays of indexes + elements Of course, collections would need to be recursively disassembled in the same way entities are. So far, so good. This is not too difficult to do. You would need to implement disassemble() on CollectionPersister, perhaps. Now, the bit I'm not 100% sure about: entities are cached when they are first loaded which means that any lazily initialized collections are uninitialized at that point. This suggests we leave (4) above unchanged and give the collection role its *own* cache and have the code on SessionImpl that initializes collections cache the collection in the collection cache when it is first initialized. of course, this means we have to carefully lock() / unlock() the collection's entry in the cache from the execute() method of the ScheduledCollectionXXXX classes. (Notice that lock / unlock deliberately doesn't stop any other thread from accessing the object from the database, only the cached version.) I *think* all this is okay and doesn't break anything w.r.t Hibernate's optimistic locking model (where version numbers are always maintained by the parent entity of a collection). So to summarize, the steps would be: (1) Implement code to disassemble collections. This would involve some (little) code on the classes in cirrus.hibernate.collections, together with some tree-walking algorithm on CollectionPersister. You might want to refactor some tree-walking code out of ClassPersister to help with this (or not, perhaps) (2) add a call to cache the collection from SessionImpl.initialize(PersistentCollection) this would be a call to the CollectionPersister and then eventually to it's cache (3) add calls in the ScheduledCollectionXXXXX classes to lock() the collection in the cache, before updating it (4) add code in SessionImpl.releaseLocks() to unlock() the collection in the cache. I think a small bit of redesign would be worthwhile here - rather than having SessionImpl maintain a list of cache locks it needs to release, it could instead remember all the ScheduledXXXXX objects it executed and make them each release the cache lock they acquired. So change the interface SessionImpl.Executable, adding a method afterTransactionCompletion(). Does all that make sense? I'm happy to work together with you on this one. Theres a few different tasks there that are somewhat parallelizable. Gavin ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
