> 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. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
