We got rid of backup file a while ago.
- Kedar
Lloyd L Chambers wrote:
> I see no need to reserve disk space. Why can't we use the same
> technique I used for PasswordAdapter eg a temporary file? The only
> foolproof technique I see is:
>
> 1. Write the new version to a temp file.
> 2. Rename the old copy to something
> 3. Rename the temp file to domain.xml.
>
> Worse case: no domain.xml, but the old version remains intact.
>
> This is the time-proven approach. On Mac, there is even an atomic call
> to do 2 and 3 together.
>
> Lloyd
>
> On Sep 21, 2007, at 1:57 PM, Kedar Mhaswade wrote:
>
>>
>>
>> Mark A. Basler wrote:
>>> Hi Kedar,
>>> For the people who don't utilize this mechanism, shouldn't we also
>>> add a check of the disk space before domain.xml is flushed? If there
>>> isn't enough disk space to write domain.xml out, then don't allow an
>>> update.
>>
>> That will affect every write operation, which, I am not sure is
>> desirable.
>> If this is a reasonable overhead that is required to have even when
>> we have ample disk space, we can do it.
>>
>> Also, do you know an API in Java that tells us if one has disk space
>> of a given
>> size?
>>
>> Another problem is, even if such API returns "true", by the time
>> actual flush
>> occurs, the disk might be occupied, as you have no control over what
>> threads
>> use the disk for what purposes and which write succeeds.
>>
>> So, a "reactionary" approach where we attempt to protect the
>> domain.xml only
>> when we fail to do write it sounds reasonable.
>>
>> Again, this technique does have flaws and it is not fool-proof. But it
>> is better
>> than nothing, given the constraints. The only other technique that can
>> help is
>> using RandomAccessFile, but I have to explore it.
>>
>> Please let me know if this needs to be ported to UR1 and if yes,
>> kindly add
>> the hook that allows me do that.
>>
>> Thanks,
>> Kedar
>>
>>> This way you always have the current running domain.xml on disk.
>>> My 2 cents...
>>> Thanks - Mark
>>> Kedar Mhaswade wrote:
>>>> Finally, I have been able to fix this problem (reasonably).
>>>>
>>>> All about it can be found at:
>>>> http://wiki.glassfish.java.net/attach/GlassFishAdminReferences/6505045.html
>>>>
>>>>
>>>> Please go through the background and code changes if you have time
>>>> and let me
>>>> know if you have any comments, by tomorrow 12.00 noon, pacific.
>>>>
>>>> I am planning to check this in then, on GlassFish trunk.
>>>>
>>>> Mark Basler: I leave it up to you to approve the fix for 9.1 UR1. If
>>>> you do
>>>> want to do that, let me know and I can port the changes there.
>>>>
>>>> I have run the tests on my 128M Zip-drive on Mac OS X by observing
>>>> domain.xml go
>>>> to zero-bytes and domain.xml.protect coming to rescue, making every
>>>> attempt
>>>> to persist the domain.xml.
>>>>
>>>> Regards,
>>>> Kedar
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>