🚀 go-pugleaf

Craig Wilson wrote:

> I'm using xml files as a sort of database, with Castor doing the reading and
> writing.  I want to make the program multiuser, so that when one user
> accesses a certain piece of data, no one else can edit it, until the first
> guy is done with it.  The method I'd like to try is to have a text
> (preferably xml) file that would contain a list of locked data elements.
> When you are ready to work on some data, you would have to open that file
> and check to make sure that data element isn't listed.  If it's there, show
> a please try again later message, otherwise write that data element to the
> file and proceed, then remove that element from the file when finished with
> it.  But for that to be safe, only one person can be allowed to have the
> file open at any one time.  Is there a way to lock the file for this
> purpose?  Or any other suggestions would be appreciated.
> Craig
> 
> 
Well, concurrent access is the classic reason to use a database, because 
it normally handles the associated lock release problems when a client 
that originally locked the resource "goes away". If you don't want to do 
that, one common approach is to use another file as a semaphore. The 
semaphore is a "logical lock" that signals other clients not to access 
the resource it is associated with.

So, for example, when you want to access the XML file, you do something 
like this:

try {
    File f = new File( MY_SEMAPHORE_FILE );
    boolean createdSemaphore = false;
    while ( !createdSemaphore &&
            <other conditions like a timeout for example> ) {
       try {
          createdSemaphore = f.createNewFile();
          if ( createdSemaphore ) {
             // I created the semaphore, so I can access the XML file
             <do XML access here>

          }
       } finally {
          if ( createdSemaphore ) {
             try { f.delete() } catch (Exception e ) {};
          }
       }
    }
} catch (Exception e ) {
   // Handle it
}


The downside to this approach is that if the client creates the 
semaphore, then crashes without deleting the file, your other clients 
are stuck. Again, this is one of the advantages of a real database, that 
will release locks held by a client that it deems "has gone away".

-- 
Tad Frysinger [TeamB]