🚀 go-pugleaf

Tad:

Thanks for the reply.  That's almost exactly what I ended up doing.  By
having the only programmatic access to the xml file of locked records occur
between CreateNewFile and erasing it, I ensured that only one user could be
in the sentinel file at one time.  All working well.  I'm aware of the
potential for leaving the sentinel file in place, so I added a "Reset Record
Locking Mechanism" button to the app which erases the sentinel file and
deletes the locks in the xml file of locks.  Not ideal for a network of any
size, but for this particular situation it should be safe.  Down the road I
plan to develop database support using Castor so that either approach would
work.  Obviously fewer installation hassles if we can avoid a database.

Craig

"Tad Frysinger [TeamB]" <tfrysinger@earthlink.net> wrote in message
news:3f9550ed$1@newsgroups.borland.com...
> 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]
>