So if I understand it, what used to happen is that there were infrequent
errors on CREATE with "file already exists" message. Now, it may get the
same message, but only after waiting 10 seconds. Given the infrequency of
the problem. And the fact that the failed create tablespace can be retried
with probably success. I agree that simple is better.
>-----Original Message-----
>From: Vladislav Vaintroub [mailto:vaintroub@stripped]
>Sent: Monday, June 09, 2008 5:14 PM
>To: 'Kevin Lewis'; 'Vladislav Vaintroub'; commits@stripped
>Subject: RE: bzr commit into mysql-6.0-falcon:mysql-6.0-falcon branch
>(vvaintroub:2685) Bug#36396
>
>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?
>>
>
>
>
>--
>MySQL Code Commits Mailing List
>For list archives: http://lists.mysql.com/commits
>To unsubscribe: http://lists.mysql.com/commits?unsub=1