On Wed, 02 Apr 2003 11:10:04 -0600
gerald_clark <[EMAIL PROTECTED]> wrote:
> A Checks for empty
> B Checks for empty
> A Updates
> A Reads ( and owns record )
> B Updates
> B Reads ( and owns record )
>
Reality says to do it more like this....
A Write lock on table
B Tries to write lock, can't, wait
A Checks for emtpy
B Tries to write lock, can't, wait
A Update
B Tries to write lock, can't, wait
A Reads (and owns record)
B Tries to write lock, can't, wait
A Release Write lock on table
B Write lock on table
B Checks for empty, not empty, record in use.
A Tries to Update, can't because of write lock by B
B Releases write lock
A Updates Record (removing row lock)
B Write lock on table
B Checks for empty
B Update
B Reads (and owns) record
B Release write lock on table
B Updates record (removing row lock)
Of course, B should be able to timeout (not block
indefinately), and there should be some way to
recover locked rows where process A crashes and
can't update the row to make it available again.
I'm not sure what mysql does if a connection is
lost to a client that owns a table lock... If
mysql doesn't auto clean up the table locks, then
that will need to be coded as well.
function lockrecord(id, table)
{
retval=FALSE;
retries=0
while (!((locked = locktable(table))) || (retries == 5))
{
sleep(10);
retries++;
}
if (locked)
{
if (record_available(id))
{
if (update_record_lock(id))
{
retval = TRUE;
}
}
unlocktable(table);
}
return(retval);
}
Or, you could build the retries and sleep into the locktable()
function and only have it return true or false...
--
Eric Calvert
kyconnection.com, inc.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
