sounds good to me.
On 10/22/2010 03:50 PM, Bill Shannon wrote:
> 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>