Justin/Matthew, thanks for your replys. After some more research, it
looks like MySQL does have some provisions for doing what I need, either
thru constructive queries which can emulate row/column leveling locking
as seen here:


Or using cooperative advisory locking as mentioned here:


Regardless, this has become more of a MySQL list and I will post there
from now on. Just wanted to pass on my findings in case anyone else was
interested. Thanks for your time.

> -----Original Message-----
> From: Justin Buist [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 12:40 PM
> To: Barry L. Jeung
> Subject: Re: [PHP-DB] Application-based locking with PHP?
> 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: 
> >

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]

Reply via email to