I believe there's a problem with synchronization of instances
at startup. You'll recall that synchronization is primarily
based on whether domain.xml is out of date.
What happens if there's a network or system failure part way
through synchronization?
The domain.xml file is the first file synchronized. If synchronization
of that file succeeds, and then there's a failure, the next start of
the server after the failure will conclude that the server is fully
synchronized. Clearly not what we want.
What if we rename the new domain.xml file, or reset its mod time,
after it's downloaded? Well, there's still a window in there where
a failure can occur.
What if we download the domain.xml file to a separate location and
then move it into the correct location as the last step of
synchronization? Well, we could still end up with an application
that is half synchronized or a library that is half synchronized,
although their mod times shouldn't be updated until the file or
directory is completely stored. Still, it seems like there might
be holes here.
Instead, here's what I'm proposing...
When starting synchronization, I'll create a ".syncstatus" file,
possibly containing information about what I'm about to do. When
synchronization is done, I'll remove the file.
If I find that the file exists when I start synchronization, I'll
force a full synchronization. Using "--sync none" will ignore
this file. Using "--sync full" will ignore this file, but will
remove it when done.
Comments?