Thomas Dudziak wrote:
For me the logical place to put the time-to-live is at the ClassDescriptor
level, since I think this info statically belongs to the class definition.
I do not see the use-case where cache TTL for a specific class should be
different between different jcd:s?
Imagine a larger-scale web application (load-balanced etc,) that is
meant to run on a DB2 database. For development and unit test purposes
the developers might probably want to use not a fully-fledged DB2 but
rather a local (embedded) Derby. But with the cache-settings for the
big database (which might even use a different cache altogether) this
will likely lead to problems.
I think it's enough with the current global cache-config TTL plus the
possibility to override it on the class-descriptor level.
I was wondering whether a more configurable strategy will help here.
For instance, we could allow the user to define the classification
himself, e.g.
<class-descriptor ... longevity="short">
<class-descriptor ... longevity="really-short">
which can them be mapped in the cache-descriptor to timeouts (and
other info where necessary):
<object-cache ...>
<cache-class name="really-short" timeout="100"/>
<cache-class name="short" timeout="1000"/>
</object-cache>
This would allow for pluggable caches (e.g. a cache for a local
database might define the same timeouts for these thus making them
equivalent), and the developers can specify their intention regarding
the longevity of the classes.
Hmm... I'm still not convinced that cache TTL has more to do with the
DB specifics than the object model/class specifics but since the
example is flexible enough to support both it's fine by me. :)
(Although the naming should be tweaked a bit in the example,
since 'short' et al is not a class as in cache-class.)
What I had in mind before was something like:
<class-descriptor ... cache-timeout="1000">
Where I have seen the need for this, some objects are extremely long-lived
and most others not. Regression tests etc are not concerned about cache
timeouts at all (the cache should be, and is currently, completely transparent)
- HSQLDB or Oracle would use the same object-level caching timeouts.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
