List:Internals« Previous MessageNext Message »
From:Paul Cadach Date:September 7 2001 5:07am
Subject:Re: LOCK TABLES on compressed tables - READ WAIT lock type...
View as plain text  
Hi,

----- Original Message -----
From: "Dana Powers" <dana@stripped>
To: "Paul Cadach" <paul@stripped>
Cc: <internals@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
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 )
> dpk

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.

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...

Other application (not application1 and application2) can uses those datas
and may requires locking too.


WBR,
Paul.


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