RE: bzr commit into mysql-6.0-falcon:mysql-6.0-falcon branch (vvaintroub:2685) Bug#36396

[Vladislav Vaintroub]

Kevin, polling for a file name while there are drop tablespace operation in
progress is among the simplest things one can do here.
"DROP TABLESPACE" is a rare operation and even failure after 10 seconds of
waiting is non-fatal, so I think simplicity has its merits in this case and
IMO beats tricks and technical elegance.

Sure, one can do something more complicated. For example

a) Block all CREATE TABLESPACE operations while there is a  DROP TABLESPACE
is in progress 
 - count pendingDrops as currently
 - introduce syncCreateTableSpace , that should be locked exclusively during
CREATE TABLESPACE operation in the client thread
 - during DROP TABLESPACE, client thread atomically increments pendingDrops.
If it is 1, syncCreateTablespace is locked.
 - Gopher thread decrements pendingDrops. If it became 0,
syncCreateTablespace is unlocked

b) Create a queue consisting of files to be deleted  with a SyncObject per
each file. During drop in client thread, lock SyncObject.
Release lock on SyncObject, when file is removed by the gopher.

c) Transaction doing DROP TABLESPACE waits until gopher thread is finished
(unfortunately against all current Falcon design)


Given a) b) and c) I still would still vote for original solution (polling),
but this is just my personal preference.

> -----Original Message-----
> From: Kevin Lewis [mailto:klewis@stripped]
> Sent: Monday, June 09, 2008 10:27 PM
> To: 'Vladislav Vaintroub'; commits@stripped
> Subject: RE: bzr commit into mysql-6.0-falcon:mysql-6.0-falcon branch
> (vvaintroub:2685) Bug#36396
> 
> Vlad,
> 
> I do not like the 10 second wait inside
TableSpaceManager::createTableSpace
> for a drop to complete before creating a new one.  Is there a more
> deterministic way of doing this?
>