Board index » jbuilder » File locking

File locking


2003-10-16 01:31:02 AM
jbuilder6
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
 
 

Re:File locking

Craig Wilson wrote:
Quote
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]
 

Re:File locking

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]" < XXXX@XXXXX.COM >wrote in message
Quote
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]

 

{smallsort}

Re:File locking

Craig Wilson < XXXX@XXXXX.COM >wrote:
Quote
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.
Not if it's a simple one --- your task description sounds very much
like the new XML-extended edition of Berkeley DB could make your day.
--
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.
 

Re:File locking

We are attempting to move to StarTeam after using Jedi/FreeVCS. In that
environment, we became used to - and liked - the way we could not edit
files that were not checked out because they were marked read-only upon
checkin. No need to see if the file has been checked out, no merging -
worked very well for us, most of the time.
StarTeam looks like it can be configured to behave the same way,
offering options to "Exclusively lock on check out", "Clear file lock on
checkin" and "Mark unlocked files read only." I'm trying to implement
these settings but have questions, and am running into problems:
1) It seems that you can make this behaviour default to a specific
project but not to all projects. So we'd have to go back in and
administer each new project to implement these options?
2) After reconfiguring some projects to use these options, I found that
I could no longer access some source as I expected. It seems that
because the .dpr and .bdsproj files end up getting marked as readonly
Delphi and/or StarTeam won't let me do anything with the other units.
Is there a way to tell StarTeam to not mark the project files readonly,
only the units?
Thank you!
 

Re:File locking

(1) yes - have to do for each project
(2) there's no way (afaik) to differentiate certain files for these
behaviors. Best advice is to not checkin the project file -- not real good
advice, but best available (afaik)
"Sean Gifford" < XXXX@XXXXX.COM >wrote in message
Quote
We are attempting to move to StarTeam after using Jedi/FreeVCS. In that
environment, we became used to - and liked - the way we could not edit
files that were not checked out because they were marked read-only upon
checkin. No need to see if the file has been checked out, no merging -
worked very well for us, most of the time.

StarTeam looks like it can be configured to behave the same way, offering
options to "Exclusively lock on check out", "Clear file lock on checkin"
and "Mark unlocked files read only." I'm trying to implement these
settings but have questions, and am running into problems:

1) It seems that you can make this behaviour default to a specific project
but not to all projects. So we'd have to go back in and administer each
new project to implement these options?

2) After reconfiguring some projects to use these options, I found that I
could no longer access some source as I expected. It seems that because
the .dpr and .bdsproj files end up getting marked as readonly Delphi
and/or StarTeam won't let me do anything with the other units. Is there a
way to tell StarTeam to not mark the project files readonly, only the
units?

Thank you!