List:Internals« Previous MessageNext Message »
From:Benjamin Pflugmann Date:September 7 2001 8:34am
Subject:Re: LOCK TABLES on compressed tables - READ WAIT lock type...
View as plain text  
Hi.

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.

Bye,

	Benjamin.

Thread
LOCK TABLES on compressed tables...Paul Cadach5 Sep
  • Re: LOCK TABLES on compressed tables...Sinisa Milivojevic6 Sep
  • Re: LOCK TABLES on compressed tables...Paul Cadach6 Sep
    • Re: LOCK TABLES on compressed tables...Michael Widenius6 Sep
  • Re: LOCK TABLES on compressed tables...Timothy Smith6 Sep
  • LOCK TABLES on compressed tables...Michael Widenius6 Sep
  • Re: LOCK TABLES on compressed tables...Paul Cadach6 Sep
    • Re: LOCK TABLES on compressed tables...Timothy Smith6 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Dana Powers7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
    • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Timothy Smith7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
    • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Benjamin Pflugmann7 Sep