Critical Section Problem in Java

ok... this is the problem i need support with:

I need to open a document in java from more than two interfaces and apply a synchronised editing feature....to my knowledge, that requires me to apply a critical section problem in the document...as far as i know, there is no Java module for the same....

so, can anyone guide me about how to do it...or if they have a different approach, please explain it to me...

 

I am just getting into this myself. I think I would first try having a cental place where document parts can be registered as locked, such as a temporary file next to the one you're working with, a shared database, or the master editor if you use master/slave (server/client) communication. Locks can be just references to the place in the file that is locked. The locking class should check that the lock is successfully made before continuing, and you could include timestamps so the class can unlock old locks from when other programs crashed or something. If there are no more locks, the file can be deleted. If a lock is made with no file there, it is created. You would need to lock the document while making changes, although I think Windows usually does that automatically? I would use line numbers as locking points, although insertion or deletion of lines would mean changing the locks. To avoid this, you could have a master divide it into section objects, and manages locks and disperses them to the clients when they request them. When they edit one, they tell the master which confirms the edit to them (perhaps after saving the changes to the file by putting the sections together again.) The trouble with a master is that if it quits for any reason, you lose the locks. Another client can become master if it finds none exists (this may require a dance to get right) and re-divide the sections and reconcile with the other clients what they know about the sections. If that dance is too much, just restart them all.

Another approach would be to merge changes all at once while saving, but that can get complicated. lol

You could also lock the entire document so only one program could write to it at one time, and other can read it, but not let the user modify the contents until the other user's change is made, and the document is read/write again. This is not using Windows permissions, exactly, as it will change during the time the document is open, and I don't know how well Windows handles this. I would use a separate file or database entry to tell when it was ok to allow editing. If the file (or db key) exists, don't allow editing. When an edit is made, create the file, save the document, and delete the file. This would be annoying to users if they had too much of a delay while a change was being saved, such as if there were many users or a slow connection or slow device.

 

ok...even before PC-XT had made a reply, i had tried something...

but first, let me clarify, as i din mention it earlier...i am using JAVA for this particular application as i want to run it on my school network, which uses a mix of windows, linux and mac...so, windows locks are out of the question....i am just goin to use java resources....

secondly, i tried to make a master slave structure, but i could not get it right at all...the document would be accessible from both the interfaces, but i could not lock it in the master as i dont know how to use line numbers to lock the document....then i tried to lock the entire document through a master, and identify a slave to edit it...the problem is once i edit it through the slave and try to save it, the master crashes, probably because it can not identify the new, edited document.....

i would continue to work on it.....meanwhile, any support is appreciated...and almost forgot....thnx PC-XT for takin out the time to answer me

 

I tried dividing the document into lines, and treating each separately. I then compare each line changes individually. I also tried per paragraph, but that wasn't as easy to implement, since some documents had different ways of defining a paragraph. (Some use lines and word wrapping, while others use 2 carriage returns or some other thing.) For Java, I put these smaller units into a collection object subclass or similar object (with methods to compare the document or parts of it and whatever else is needed) to treat it as one document. (I often actually make a new object with an array to hold the lines instead of subclassing.)