Return-Path: 
 <ojb-dev-return-12407-apmail-db-ojb-dev-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-ojb-dev-archive@www.apache.org
Received: (qmail 70719 invoked from network); 27 Jun 2005 10:44:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 27 Jun 2005 10:44:23 -0000
Received: (qmail 40121 invoked by uid 500); 27 Jun 2005 10:44:23 -0000
Delivered-To: apmail-db-ojb-dev-archive@db.apache.org
Received: (qmail 40067 invoked by uid 500); 27 Jun 2005 10:44:22 -0000
Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ojb-dev-unsubscribe@db.apache.org>
List-Help: <mailto:ojb-dev-help@db.apache.org>
List-Post: <mailto:ojb-dev@db.apache.org>
List-Id: "OJB Developers List" <ojb-dev.db.apache.org>
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Delivered-To: mailing list ojb-dev@db.apache.org
Received: (qmail 40054 invoked by uid 99); 27 Jun 2005 10:44:21 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jun 2005 03:44:21 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [213.115.149.212] (HELO manta.curalia.se) (213.115.149.212)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jun 2005 03:44:21 -0700
Received: from manta.curalia.se (manta.curalia.se [213.115.149.212])
	by manta.curalia.se (Postfix) with ESMTP id E67D4ABC031
	for <ojb-dev@db.apache.org>; Mon, 27 Jun 2005 12:44:12 +0200 (CEST)
Received: from [172.20.6.103] (raa-se.raa.se [193.10.40.128])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by manta.curalia.se (Postfix) with ESMTP id D679FABC008
	for <ojb-dev@db.apache.org>; Mon, 27 Jun 2005 12:44:12 +0200 (CEST)
Message-ID: <42BFD879.5010705@apache.org>
Date: Mon, 27 Jun 2005 12:44:09 +0200
From: =?ISO-8859-1?Q?Martin_Kal=E9n?= <mkalen@apache.org>
Organization: ASF
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: RFC: Multi-Level Timeouts for Default Cache
References: <316E5B943771D311BAC500805FD7A078043C1DA8@MAIL.osn.state.oh.us>
	 <42BFB95D.7000902@apache.org> <224f323405062702007cac6f41@mail.gmail.com>
In-Reply-To: <224f323405062702007cac6f41@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AV-Checked: ClamAV using ClamSMTP
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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