Before the JDO spec introduced the concept of application-defined flush(), the evict method could be used to make an instance hollow and therefore subject to garbage collection.
When we introduced flush(), it became possible for all of the application state in the cache to be erased from the cache, leaving only the life-cycle state of the instance in memory for future reference.
My proposal is to require that the JDO implementation treat flushed dirty instances the same as hollow and persistent-nontransactional instances, allowing them to be garbage collected. The uniqueness guarantee only applies if the application itself holds a strong reference to the instance.
This proposal would allow a well-designed program that creates or updates a large transaction set of persistent instances to flush periodically and not run out of memory.
If an application constructs a large number of instances and flushes them, the only artifact remaining in the cache would be the memory that the instance was new. That is, if the instance were subsequently queried or obtained by id, the instance would still be persistent-new although the instance retrieved might be a different Java instance from the instance created and flushed.
We could still use the evict method to remove even the memory of the life cycle state of the instance. So if the persistent-new instance were flushed, it would still be persistent-new, but if it were then evicted, it would be subsequently retrieved as a hollow or persistent- nontransactional instance.
Please comment. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
