Kedar,
The only reliable way I know of to do this with minimal risk is to
use a temporary file.
Why use an alternative with the complexity of two system properties?
Is that approach superior in some way? If I'm missing something
here, please explain.
You asked for a review. I vote "no" unless you can explain why your
solution is as good or better than the alternative of using a
temporary file.
(And if in fact a decision was made to risk data loss in lieu of
using a temporary file, then we should reverse that malfeasance ASAP).
Lloyd
On Sep 21, 2007, at 2:56 PM, Kedar Mhaswade wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>