On Fri, Sep 07, 2001 at 12:07:14PM +0700, paul@stripped wrote:
> > Sounds like you want a simple mutex - doesnt seem connected to the
> > specific table at all. Whats wrong with using the
> > GET_LOCK('TABLE',10) command then? ( see docs here:
> > http://www.mysql.com/doc/M/i/Miscellaneous_functions.html )
> Just because I needs mutexes on set of tables (so, I must set set of locks
> simultaneously, GET_LOCK() doesn't provide this feature).
I don't see the problem. Indeed, you can use just one mutex to mark
the set of tables locked.
> Ok, I've describe my situation to provide more information.
> Used tables:
> 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...
Assure that application2 issues something like
SELECT GET_LOCK('application2', 10)
and check the result. Then there will be never running two instances
of application2 queries on table2/table3 at the same time.
> Other application (not application1 and application2) can uses those datas
> and may requires locking too.
This, of course, may be or problem or not, depending on the
interaction and if you can fit them into the locking/mutex scheme.