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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
