db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clute, Andrew" <Andrew.Cl...@osn.state.oh.us>
Subject RFC: Multi-Level Timeouts for Default Cache
Date Fri, 24 Jun 2005 15:32:02 GMT
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
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,
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message