commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@apache.org>
Subject Re: [configuration] Configuration 2.0 - Persistence
Date Thu, 18 Jun 2009 10:10:34 GMT
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


Mime
View raw message