So long as you keep any referencial integrity from being broken by two
nearly simultaneous updates I don't really see much of a problem. If two
users update a trouble ticket what's the big issue? Perhaps a
notification could be displayed on the update confirmation page letting
one of the user's know that somebody else updated it while they also did.
Take a look at bugzilla -- it chugs along just fine it seems w/out any bug
locking mechanism.
Probably not the ansewr you were looking for, however if you're still
hellbent on getting a real locking mechanism in place you may wish to take
a look at SysV semaphores at http://www.php.net/manual/en/ref.sem.php.
<Overkill solution>
If you're familiar with using them in C you should be able to pick right
up on it; if not then you may wish to consult manpages of whatever OS
you're using (I assume *nix) for the C counterparts:
man 2 semget
man 2 semctl
man 2 semop
man 5 ipc
man 3 ftok
Even if you use them, which should be more trustworthy than DB locking,
you end up with the problem of unlocking it after the user has exited.
Perhaps you could use the shared memory functions to insert a timestamp at
which the semaphore expires, store that stamp in session variable, then
before the update compare the session variable with the value in shared
memory. If they don't match they've lost their lock because they took too
long to update and somebody else now has the semaphore and is in control
of the update. Rather than lock on the ablitity to update the DB though
you have to lock on the ability to look at and update the shared memory
segment. I don't think PHP has an application-wide variable scope, so
shared memory is probably your only option. And hey, if you're dealing
with SysV semaphores anyway you might as well just do the whole thing in a
SysV IPC style. :)
</Overkill Solution>
If it's really -really- important, that's the only truly solid option I
see. If it's not this important the I'd dump it, let people muddle with
the same ticket at once and let them sort their differences out later.
Justin Buist
Trident Technology, Inc.
4700 60th St. SW, Suite 102
Grand Rapids, MI 49512
Ph. 616.554.2700
Fx. 616.554.3331
Mo. 616.291.2612
On Mon, 17 Sep 2001, Barry L. Jeung wrote:
> Just wondering if anyone has tried doing quasi application based locking
> with PHP? My scenario is this. I'm constructing a database for my
> company to help keep track of trouble tickets, etc with a web-based
> frontend. I'm using PHP (obviously =]) for inputing/retrieving data and
> have a slight predicament. Since MySQL does table-level locking, if I
> put lock statements in my queries, it would cause two problems. One
> being the entire table being locked and two if the user just closes the
> webpage without exiting properly, the table would remain locked
> indefinately. So I'm trying to think of alternatives, one of which is
> using global variables to store table/record id's, and then evaluating
> the queries based on that information. So if John selects ticket # 5 and
> might be updating it, then when Bob attempts to select ticket #5, then
> the $id and $table variables would be checked against the variables
> stored when john placed his query, and bob would get a message saying
> that record #5 is locked or in-use by John and to try later. Is this
> feasible or is there a better way to do this? Thanks for your time.
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
