[sip-comm-dev] Improving MCL storage. Brought to u by Ben!

Alexander Pelov a_pelov at yahoo.com
Sun Sep 16 14:30:24 CEST 2007

Hi everyone,

the question in hand is very interesting - what to do when an error  
occurs while replacing an existing (and potentially important) file.  
Maybe we can create a sort of a generic API that can emulate  
transactional behavior on top of a general FS. I am thinking about  
something like this (if we are following Java Transaction API http:// 

File f = new File("/test.xml");
Transaction trans;
try {
	trans = FileTransaction.beginTransaction(f);
	// some actions with f
catch(Throwable e) {
	throw e;

Following JTA would require that the originating file is copied when  
beginTransaction is called. On commit() the backup file should be  
deleted, whereas on rollback() the backup file should replace the  
invalidated "f". Here, there are some potential issues, but I think  
that they can be addressed relatively easily. The default behavior  
would be to automatically rollback a transaction. This way, one may  
encapsulate all kinds of file operations in transactions and in case  
of unexpected exceptions, kernel panics, premature application  
termination, etc. data corruption would be kept to minimum.

A simpler approach would be to write all changes to a secondary file,  
and once done - replace the original. An example would be like:

File f = new File("/test.xml");
Transaction trans;
try {
	trans = FileTransaction.beginTransaction(f);
	File newFile = trans.getProtectedFile();
	// write to newFile and potentially read from f
catch(Throwable e) {
	throw e;

An example behavior of the different functions could be:

create a file "/test.xml.tmp03942940192.transactionbackup"

1) Rename "/test.xml" to "/test.xml.tmp01293093.original"
2) Rename "/test.xml.tmp03942940192.transactionbackup" to "/text.xml"
3) Delete "/test.xml.tmp01293093.original"

Of course, one would always have to access a file in a transaction  
(or at least call a function that would search for eventual  
"....original" and ".....transactionbackup" files and perform  
appropriate actions.

What do you think ?


Le 16 sept. 07 à 13:39, Benoit Pradelle a écrit :

> I Emil,
> Emil Ivov a écrit :
>> Hi Ben,
>>> I'm deleting the backup file only to simplify the work when SC  
>>> restarts:
>>> If a backup is present, we use it because it means that the last  
>>> write didn't finish correctly, else we do the normal job.
>>> If the backup file is never deleted it is more complex to  
>>> determine if the last write was successful: maybe the original  
>>> file is correct and contains the modification, maybe the shutdown  
>>> occurred just before the write or worst, maybe the write is only  
>>> partial. Then, when SC restarts, it become very difficult to  
>>> determine what file to use.
>> I am not sure I get this. The way that things are currently  
>> implemented
>> we have:
>> 1) Create original; 2) Create copy; 3) Delete copy
>> After a normal execution of the sequence we would end-up with only  
>> the
>> original and no copy because it would be deleted.
>> Then let's say that the program exits unexpectedly and the process  
>> gets
>> interrupted in step 1. Step 2 would never happen since the program  
>> died
>> and the backup file from a previous execution of the sequence  
>> would have
>> been deleted. So next time we start SIP Communicator we'd still be
>> unable to reload the contact list since there won't be any backup.
>> If you don't delete the copy however everything falls into place.  
>> If the
>> process is cut in Step 1, you would have the backup from the  
>> previous run.
>> If a shutdown happens normally in this case you would indeed have an
>> unnecessary backup but this won't be a problem. I don't think this  
>> makes
>> it difficult to determine which file to use. You always load the  
>> primary
>> file and only use the backup if loading the first one has failed.
>> Does this make any sense?
> In fact the algorithm is a little bit different than what you  
> described:
> 1) copy the original contact list
> 2) modify the contact list
> 3) delete the backup file
> this way, if a backup file is present it contains an older but  
> valid contactlist.
> However, while I'm writting these lines I'm thinking at a possible  
> error case: if the stop occurs during the copy of the original  
> contact list, the backup will be loaded at the next SC start even  
> if it isn't correct. So it seems that I still got some work on it :)
>>> I also would like to complete your explications by saying that  
>>> this little patch is only a first step because this problem also  
>>> occur sometimes with the sip-comunicator.xml file and perhaps  
>>> others so it'll probably be a new plugin or service able to  
>>> handle secured write to important files.
>> Cool! Glad to know that this is also in your plans! After we have  
>> tested
>> this in the meta contact list we could actually try to bring it  
>> out in a
>> service. WDYT?
> It's exactly what I was thinking :)
> Cheers,
> Ben
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help at sip- 
> communicator.dev.java.net

To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

More information about the dev mailing list