Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A3A129A.2050607@apache.org>
Date: Thu, 18 Jun 2009 12:10:34 +0200
From: Emmanuel Bourg <ebourg@apache.org>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] Configuration 2.0 - Persistence
References: <4A321298.4030209@apache.org>
 <31F6CF48-13A1-4E43-ACAD-329A980764A3@dslextreme.com>
 <4A33BFAC.5060502@oliver-heger.de>
In-Reply-To: <4A33BFAC.5060502@oliver-heger.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Oliver Heger a �crit :

> There are certainly some use cases that would benefit from a generic 
> flush() method, e.g. just tell a composite configuration to save its 
> changes, and it iterates over its children and flushes them.

Yes, this is one of the main use case I have in mind (that's 
CONFIGURATION-159).


> However, there are lots of details that have to be cleared, for instance:
> - How are configurations treated that are not really "compatible" with a 
> manual save operations, e.g. JNDIConfiguration or DatabaseConfiguration?

These configurations can benefit greatly from this feature. For example 
CONFIGURATION-180 is about caching the changes made to a 
DatabaseConfiguration and saving them periodically to improve the 
performances. That's exactly what sync() and flush() are meant for (or 
reload() and save(), I have no preference on the name).


> - What about pure in-memory configurations?

For pure in-memory configuration the flush()/sync() methods just do 
nothing. Since the memory is the backend, the configuration is always in 
sync.


> - Or URL-based configurations without a valid URL?

What happens today with a PropertyConfiguration with autoSave enabled 
and an invalid URL?


> Not sure how a sync() operation would fit into the concept of the 
> library. I assume it is like a manual reload, but (in addition to the 
> questions above):
> - What happens to changes performed on the configuration objects? Are 
> they overridden? Is a merge tried?

This could be configurable. The data in the backend could override the 
changes in memory, or we could attempt a merge and give the priority to 
the backend change or to the local change if a conflict is detected on a 
property.


> - When in the life-cycle of a typical application should the sync() 
> method be called?

I was thinking about a generalized ReloadingStrategy that decides when 
to sync, and maybe a SavingStrategy that decides when to flush(): never, 
or automatically after each change (equivalent to autosave=true), or 
every n minutes, or 10 seconds after the last change, etc.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org