On 12/06/2010 02:51 PM, Marc Morin wrote:
We've found that our application is not useable (according to our
> customers) without entity caching enabled.
There are simliar issues with the forced-creation of http sessions
when doing read-only requests. There are calls to
request.getSession(), without passing false and checking for null.
Like I emailed previously, we've made extensive improvements on the
> entity cache to increase the hit rate (only store value once if fetched
> by pkey and then in an entity condition) and lower memory consumption,
> store objects in dictionary, so that singleton for each Object fetched
> from db, String.intern() some Field values to make "PARTY".equals(..)
> checks faster, etc.... All these changes are required for multi-tenant
> systems where the is a rather high degree of redundant information in
> each tenant instance. (think of enumerations, types, etc...)
Some pseudo-code for the features you suggest:
==
<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.
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.
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'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.
The reason for this is that GenericValue extends GenericEntity. You'd
want a FooDelegatorGenericEntity, which would be extended by
FooDelegatorGenericValue, but then the latter wouldn't be extending
GenericValue nor GenericEntity, and the ABI would be broken.
