You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by "Clute, Andrew" <An...@osn.state.oh.us> on 2005/06/24 17:32:02 UTC
RFC: Multi-Level Timeouts for Default Cache
We are starting to find the all-or-nothing philosophy of the timeout
setting for the Default Cache to be limiting. It is becoming obvious to
us that we really have 3 levels that make sense: ShortLived (current
setting), LongLived (orders of magnitude longer than current) and
Permanent.
We have implemented an extended Cache that handles these cases, but I am
realizing that this could be beneficial in the main code base for OJB.
Handling the three levels is pretty trivial, however the configuration
of it is rife with questions. The way we handled it was to create
marker interfaces that our persistent objects extended to signify that
they were either LongLived or Permanent. This caused the least amount of
changes to OJB, but probably is not the cleanest (ties objects to OJB,
etc).
The other option, and probably the better one, is add a property at the
ClassDescriptor level to signify the Cache timeout level. This has the
downside of requiring more changes (config code and XDoclet code).
So, that leads me to my questions:
1) Anyone have any issues or concerns with such a feature being added? (
I am going to start with 1.0 branch first)
2) Thoughts on the best way to handle the configuration of this? I do
know that I do not want to make it attributes to the cache itself that
marks which classes are which, this could become cumbersome as that part
of the configuration is not auto-gened by anything.
Thoughts?
-Andrew
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Thomas Dudziak <to...@gmail.com>.
On 6/24/05, Clute, Andrew <An...@osn.state.oh.us> wrote:
> We are starting to find the all-or-nothing philosophy of the timeout
> setting for the Default Cache to be limiting. It is becoming obvious to
> us that we really have 3 levels that make sense: ShortLived (current
> setting), LongLived (orders of magnitude longer than current) and
> Permanent.
>
> We have implemented an extended Cache that handles these cases, but I am
> realizing that this could be beneficial in the main code base for OJB.
>
> Handling the three levels is pretty trivial, however the configuration
> of it is rife with questions. The way we handled it was to create
> marker interfaces that our persistent objects extended to signify that
> they were either LongLived or Permanent. This caused the least amount of
> changes to OJB, but probably is not the cleanest (ties objects to OJB,
> etc).
>
> The other option, and probably the better one, is add a property at the
> ClassDescriptor level to signify the Cache timeout level. This has the
> downside of requiring more changes (config code and XDoclet code).
>
> So, that leads me to my questions:
> 1) Anyone have any issues or concerns with such a feature being added? (
> I am going to start with 1.0 branch first)
+1 for adding to 1.1,
-1 for adding it to 1.0 (if it is not configurable with the existing
mechanisms).
> 2) Thoughts on the best way to handle the configuration of this? I do
> know that I do not want to make it attributes to the cache itself that
> marks which classes are which, this could become cumbersome as that part
> of the configuration is not auto-gened by anything.
I'd rather avoid putting cache-info into the class descriptors, mostly
because this is usage (dynamic) rather than structure (static) info.
So IMO this belongs more into the jcd-part. Also, you might want to
configure the cache differently depending on the jcd, which wouldn't
be possible when attaching this info to the class descriptor.
One solution would be to have the cache configuration recognize
patterns (regex ?!) rather than direct type names.
regards,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
Martin Kalén wrote:
> Speaking of which -- isn't it already possible to tune the TTL for
> different classes when using JCS since the regions are created per FQN and the
> caching config is controlled using JCD properties?
^^^
Should be: JC_S_, not JCD.
Another small but oh so important spelling error... *sigh*
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
Brian McCallister wrote:
> I tend to think that a better approach might be to use named cache
> regions and completely leave the cache configuration up to the cache
> implementation. The default cache might have some optional config
> params to specify this, or we could default to one of the many open
> source caching implementations out there now.
OK, I am convinced - it is probably more of a caching-aspect and not
related to class-descriptors. If I think eg. JCS, the named region approach
seems straight forward. (Let's not reinvent the wheel.)
Speaking of which -- isn't it already possible to tune the TTL for different
classes when using JCS since the regions are created per FQN and the caching
config is controlled using JCD properties? I have not used OJB+JCS in a long
time and have a somewhat sketchy recollection of the details so this might be
bogus...
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Brian McCallister <br...@apache.org>.
I tend to think that a better approach might be to use named cache
regions and completely leave the cache configuration up to the cache
implementation. The default cache might have some optional config
params to specify this, or we could default to one of the many open
source caching implementations out there now.
-Brian
On Jun 27, 2005, at 7:27 AM, Martin Kalén wrote:
> Martin Kalén wrote:
>
>> <class-descriptor ... cache-timeout="john"> ;)
>> +
>> <object-cache ...>
>> <cache-class name="john" timeout="100"/>
>>
> ^^^^
>
> Caught in the Ctrl-CV process... :)
>
> Rephrase:
> <class-descriptor ... cache-timeout="john"> ;)
> +
> <object-cache ...>
> <cache-timeout name="john" timeout="100"/>
> (or:
> <cache-timeout name="john" value="100"/>)
> </object-cache>
>
> Regards,
> Martin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
Martin Kalén wrote:
> <class-descriptor ... cache-timeout="john"> ;)
> +
> <object-cache ...>
> <cache-class name="john" timeout="100"/>
^^^^
Caught in the Ctrl-CV process... :)
Rephrase:
<class-descriptor ... cache-timeout="john"> ;)
+
<object-cache ...>
<cache-timeout name="john" timeout="100"/>
(or:
<cache-timeout name="john" value="100"/>)
</object-cache>
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
Thomas Dudziak wrote:
> 'short' in the example is just some name/id that the user defined for
> one class in the longevity classification. It could also have been
> called 'John' or something :-)
> You're right though that cache-class would not be a good name, perhaps
> cache-level or similar would be better ?
cache-timeout (or similar) would be my choice, since 'level' is already
associated with one-level vs two-level cache.
>>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.
>
> But perhaps not if you use different caches, i.e. something like
> Coherence for the real app and integration testing, and a simpler
> cache for development and unit tests. After all you setup the cache
> for the target system, and usually the development systems differ from
> the target systems, esp. in terms of memory and i/o throughput.
True, then you might want to tweak cache-timeouts per jcdAlias.
As long as one can do both the simple numeric setting and
have the choice of the more advanced 'ref-id' mapping to the jcd,
the configuration covers both scenarios.
Eg:
<class-descriptor ... cache-timeout="1000">
And:
<class-descriptor ... cache-timeout="john"> ;)
+
<object-cache ...>
<cache-class name="john" timeout="100"/>
</object-cache>
I guess the final solution depends on the implementation details
of the code Andrew is about to integrate.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Thomas Dudziak <to...@gmail.com>.
> 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.)
'short' in the example is just some name/id that the user defined for
one class in the longevity classification. It could also have been
called 'John' or something :-)
You're right though that cache-class would not be a good name, perhaps
cache-level or similar would be better ?
> 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.
But perhaps not if you use different caches, i.e. something like
Coherence for the real app and integration testing, and a simpler
cache for development and unit tests. After all you setup the cache
for the target system, and usually the development systems differ from
the target systems, esp. in terms of memory and i/o throughput.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Thomas Dudziak <to...@gmail.com>.
> 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: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: RFC: Multi-Level Timeouts for Default Cache
Posted by Martin Kalén <mk...@apache.org>.
Clute, Andrew wrote:
> We are starting to find the all-or-nothing philosophy of the timeout
> setting for the Default Cache to be limiting. It is becoming obvious to
> us that we really have 3 levels that make sense: ShortLived (current
> setting), LongLived (orders of magnitude longer than current) and
> Permanent.
>
> We have implemented an extended Cache that handles these cases, but I am
> realizing that this could be beneficial in the main code base for OJB.
[...]
> So, that leads me to my questions:
> 1) Anyone have any issues or concerns with such a feature being added? (
> I am going to start with 1.0 branch first)
> 2) Thoughts on the best way to handle the configuration of this? I do
> know that I do not want to make it attributes to the cache itself that
> marks which classes are which, this could become cumbersome as that part
> of the configuration is not auto-gened by anything.
I have had similar thoughts/issues but never went as far as implementing this
feature. It is a reality in many systems that a global cache timeout for all
objects is not fine-grained enough. A big +1 for adding this!
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?
I think it's enough with the current global cache-config TTL plus the
possibility to override it on the class-descriptor level.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org