Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 3 down vote favorite

I have a project which involves re-writing pretty much all the back end of a legacy application. It uses XML for persistence and was originally written as a single user system.

With one large XML file that could be accessed by multiple users and hence get corrupted, I was thinking about introducing a SQL database where a user could work on his resource and let the database worry about concurrency.

With the short deadlines, I was wondering if we could keep the xml persistence (as well as all the business logic) and introduce locking in some other way. Is this possible?

share|improve this question
Yes, Semaphores: en.wikipedia.org/wiki/Semaphore_(programming) – jmq Feb 5 '12 at 23:07
1  
JD01 please don't sign your posts, your avatar is visible under each and every one of your posts. – Yannis Rizos♦ Feb 5 '12 at 23:22
2  
You probably need to change the XML approach for many reasons other than locking. It is inevitable that each write to the file will require writing the entire file back to disk. The performance could degrade without you being able to control it. – Emmad Kareem Feb 5 '12 at 23:22
@EmmadKareem : At the moment I have been just thinking about locking, what other issues should I be aware of when using XML? – JD01 Feb 6 '12 at 9:36
1  
You have correctly identified locking but you also need to consider speed. When you have a large file, it will take time to load, write and transfer over the LAN/Net. Also, your query options may not be as flexible as having a SQL-based database. Displaying the file effectively across pages may be impractical since you may not be able to load entire file in memory and searching the file for the next page may be too slow. If the data is supposed to grow rapidly and you expect several users to update the file concurrently, you are bound to fact one or more of these problems. – Emmad Kareem Feb 6 '12 at 15:43
show 2 more comments

2 Answers

up vote 4 down vote accepted

If you listen to some of these answers you are trading one devil for the other.

The way most people are recommending, file locking just serializes writes to the file and does not in any way address logical corruption of the structure of the XML file. It would just create a last in wins situation where previous writes are not taken into account at all.

There are transaction engines that can be added at the logical ( application ) level but unless your logic is extremely complex and ill suited to what a real RDBMS already provides they will be even more of a learning curve and even more of a maintenance issue.

Bite bullet and do it the correct way, the quick and dirty way got you in the mess you are in apparently.

share|improve this answer
Thanks, I think you are correct in saying that we have to bite the bullet now. I think management need to know that we wont finish in the timescales they want if we go down this route. – JD01 Feb 8 '12 at 9:08
up vote 3 down vote

Absolutely. All platforms have some sort of "file locking" facility. On Unix, flock and fcntl locking are available. On Windows, similar facilities exist.

http://en.wikipedia.org/wiki/File_locking has a good summary, and pointers to the implementations, as well as problems that you might encounter.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.