> ==
> <extend-entity name="Person" absorb-condition-values="true"/>
> if (modelEntity.getAbsorbConditionValues()) {
> for (GenericValue value: list) {
> cache.putToCache(value) }
> } ==
> <extend-entity name="Party">
> <extend-field name="partyTypeId" intern-value="true"/>
> </extend-entity> if (modelField.getInternValue()) {
> value = value.intern()
> } ==
>
> It would be very difficult to store the same FooType once for multiple
> tenants, as the timestamp fields might be different across
> databases(depending on when the last time seed install was run). It
> might be possible to cache value instances, using a combined weak/soft
> value map.
We maintain a weak reference map of all objects fetched from the jdbc driver.
This ensures that only a single object (being identical) will be in the JVM's
memory at a time. We don't even try to see if there is a low probability...
just put all objects into it.
>
> > Copy on write database objects, so developer doesn't need to
> > worry about corrupting other users of the data if they want/need
> > to modify an entity.
>
> In some cases, you know beforehand that you will be modifying a
> generic value; in those cases, it makes no sense to store anything at
> all into the cache. This implies you'd want an api to support
> skipping cache storage, so we are right back to having a useCache flag
> in the api.
Yes, but the JVM will keep it in memory until the garbage collector decides to
discard it. The implementation,
using WeakReferences would make it available until the JVM decides it is not
present anymore.
>
> > Transactional support for the cache. (bug vs design choice in my
> > opinion).
>
> The last time I looked for a transactional aware map(using jta), it
> didn't support generics. I found one that was close on jakarta.
We implemented our own using a Synchronization instance with the transaction
manager, one for each open transaction. Only really care about rollback or
commit. The implementation essentially guards the "committed" cache with a
per-transaction cache. New puts to the cache a put into the pre-transaction
maps, then posted to the real cache on commit. On rollback, they are
discarded. Cache gets check the transaction cache and if nothing present,
checks the commited cache.
Invalidations on the cache, occur on both the per-transaction cache and the
committed cache.
In the end, not difficult, just needed a layer between the EntityCache and the
UtilCache code.
>
> > We've turned on entity caching by "default", and would like to
> > remove the useCache from the api. Don't mind returning a
> > non-caching delegator via a delegator decorator, that way, there
> > is no API difference.
>
> Delegator proxies is something I'd like to support. However, because
> GenericEntity/GenericPK/GenericValue are classes, it makes it hard to
> proxy in all cases, so that getDelegator() returns the correct
> instance.
With our copy-on-write work, we've essentially made the GenericEntity an
interface and GenericValue extends GenericEntityDecorator. Might make it
easier to break the delegator from the entity itself.
