470,573 Members | 1,653 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,573 developers. It's quick & easy.

question about using lock files

I have a PHP user form that I supply a serial number for response
tracking. The serial number is kept in a simple text file
(tracknum.dat). When someone submits the form, PHP reads the number,
increments it, writes the new number to the file, and sends the number
back to the user for tracking purposes. To prevent two users from
getting the same serial number I put a delay loop in the script using
while(file_exists(tracknum.lock). tracknum.lock is created before
tracknum.dat is opened, and deleted after the new serial number is
written. This seems to work, but it could cause an infinite loop if for
some reason the lock file doesn't get deleted by the previous user. Am I
being paranoid about the possible infinite loop? Is there a smarter way
to do this?

Thanks

Bill
May 4 '06 #1
5 1535
William Gill wrote:
I have a PHP user form that I supply a serial number for response
tracking. The serial number is kept in a simple text file
(tracknum.dat). When someone submits the form, PHP reads the number,
increments it, writes the new number to the file, and sends the number
back to the user for tracking purposes. To prevent two users from
getting the same serial number I put a delay loop in the script using
while(file_exists(tracknum.lock). tracknum.lock is created before
tracknum.dat is opened, and deleted after the new serial number is
written. This seems to work, but it could cause an infinite loop if for
some reason the lock file doesn't get deleted by the previous user. Am I
being paranoid about the possible infinite loop? Is there a smarter way
to do this?


Nope, it works with poplock files. If you're worried, find out how old
the file is, if it's more than say 5 minutes, assume a previous error,
and delete it/carry on.

May 4 '06 #2

William Gill wrote:
To prevent two users from
getting the same serial number I put a delay loop in the script using
while(file_exists(tracknum.lock)


You have a typical race condition:

You wait until the file is deleted and then create it. Suppose that the
file is deleted and created immediatly after file_exists. The file
would be created by another process, e.g. another user requesting this
page. After the while() loop, you assume that the file still does not
exist in the next instruction, which is an unfair assumption.

May 4 '06 #3
On Thu, 04 May 2006 09:30:13 -0700, Sjoerd wrote:
To prevent two users from
getting the same serial number I put a delay loop in the script using
while(file_exists(tracknum.lock)


You have a typical race condition:

You wait until the file is deleted and then create it. Suppose that the
file is deleted and created immediatly after file_exists. The file would
be created by another process, e.g. another user requesting this page.
After the while() loop, you assume that the file still does not exist in
the next instruction, which is an unfair assumption.


From what I remember when studying for the ZCE, mkdir is atomic and
returns true or false as to whether the directory was created or not - and
hence is the best choice for locking...

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

May 4 '06 #4
On Thu, 04 May 2006 14:56:30 GMT, William Gill <no*****@gcgroup.net>
wrote:
I have a PHP user form that I supply a serial number for response
tracking. The serial number is kept in a simple text file
(tracknum.dat). When someone submits the form, PHP reads the number,
increments it, writes the new number to the file, and sends the number
back to the user for tracking purposes. To prevent two users from
getting the same serial number I put a delay loop in the script using
while(file_exists(tracknum.lock). tracknum.lock is created before
tracknum.dat is opened, and deleted after the new serial number is
written. This seems to work, but it could cause an infinite loop if for
some reason the lock file doesn't get deleted by the previous user. Am I
being paranoid about the possible infinite loop? Is there a smarter way
to do this?

Thanks

Bill

Why not try "flock"ing the file(s). YOUR process will wait for the
other (owner) task to release it before continuing.

B
May 4 '06 #5
On Thu, 04 May 2006 18:51:28 -0400, Bob_M (remove X for email) wrote:
Why not try "flock"ing the file(s). YOUR process will wait for the
other (owner) task to release it before continuing.


Errr, because of the warnings on the flock manual page:

flock() will not work on NFS and many other networked file systems. Check
your operating system documentation for more details.

On some operating systems flock() is implemented at the process level.
When using a multithreaded server API like ISAPI you may not be able to
rely on flock() to protect files against other PHP scripts running in
parallel threads of the same server instance!

flock() is not supported on antiquated filesystems like FAT and its
derivates and will therefore always return FALSE under this environments
(this is especially true for Windows 98 users).
It's not to say it won't work in his situation nor that it wouldn't be a
better solution than the one he's using, but there are other ways.

When studying for the ZCE I seem to remember either the study guide or one
of the practice exams saying to use mkdir for locks as it's a guaranteed
atomic operation and returns true/false for completion.

Cheers,
Andy
--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

May 5 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by John Sidney-Woollett | last post: by
22 posts views Thread by xixi | last post: by
7 posts views Thread by chessplayer | last post: by
3 posts views Thread by John | last post: by
12 posts views Thread by Elmo Mäntynen | last post: by
7 posts views Thread by > Adrian | last post: by
6 posts views Thread by Gina_Marano | last post: by
10 posts views Thread by e_matthes | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.