----- Original Message -----
From: "Dana Powers" <dana@stripped>
To: "Paul Cadach" <paul@stripped>
Sent: Friday, September 07, 2001 10:57 AM
Subject: Re: LOCK TABLES on compressed tables - READ WAIT lock type...
> Sounds like you want a simple mutex - doesnt seem connected to the
> table at all. Whats wrong with using the GET_LOCK('TABLE',10) command
> ( see docs here:
Just because I needs mutexes on set of tables (so, I must set set of locks
simultaneously, GET_LOCK() doesn't provide this feature).
Ok, I've describe my situation to provide more information.
table1 - data organized as set of records;
table2 - description and status of record sets in table1;
table3 - statistic on table1, also used as a flag to process a record set if
related record in table3 not exists.
Main of applications:
application1 - adds a record into table2 with indication that related record
set is just uploading, adds records into table1 (with number of this set)
then marks previously inserted record in table2 as 'uploaded';
application2 regularly (on cron schedule) looks for relation between table2
and table3 to find a records which not exists in table3 but exists in table2
and marked as 'uploaded'. If its found those records at table2 which not
present at table3, it processes records at table1 which number of set is
equal to number of set pointed at table2 then inserts a record with some
statistic information into table3.
Locking for application1 isn't required, but application2 requires
locking/mutexes to prevent processing of the same data simultaneously.
Locking must be performed on table2 because it used as a "master" to find
which sets must be processed.
To block other instance of application2 I've uses WRITE lock which blocks
execution until existing lock will be released, but it blocks application1
(and other) too...
Other application (not application1 and application2) can uses those datas
and may requires locking too.