commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
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 

> 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 

> - 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 

> - 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:
For additional commands, e-mail:

View raw message