RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2899) Bug#40302

[Vladislav Vaintroub]

> -----Original Message-----
> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
> Sent: Wednesday, November 05, 2008 6:08 PM
> To: Vladislav Vaintroub
> Cc: commits@stripped
> Subject: Re: bzr commit into mysql-6.0-falcon-team branch
> (vvaintroub:2899) Bug#40302
> 
> Vlad,
> 
> Sorry about assigning this to svoj.  I did not know you were working on
> it since you unassigned yourself.  I just assigned it back to you.

No problem, I have not even noticed that with all  mail outages today

> I think you have the right idea here, but I have a couple suggestions.
> 
> There is only one other place where a system transaction can get rolled
> back.  In StorageDatabase::renameTable() there is an exclusive lock on
> syncDDL before it calls table->rename.  Table::rename() calls
> database->commitSystemTransaction() before calling
> database->renameTable.   I think this is done so that
> database->rollbackSystemTransaction() does not roll back any other
> changes besides this renameTable.
> 
> Likewise, TableSpaceManager::createTableSpace aught to get an exclusive
> lock on syncDDL instead of a shared lock.  And the existing
> systemTransaction should be commmitted before actually trying to add
> the
> tablespace.  Also, that exclusive lock should be held throughout, just
> like in StorageDatabase::renameTable().
> 
> Kevin
> 

Do you know why we do not always use an exclusive lock ?
Current locking strategy seems buggy to me.
It looks like this on couple of places I've seen 
Shared_lock
 Log record
 <possibly more records>
Shared_unlock

(commitSystemTransaction)
Exclusive_lock
 Commit
Exclusive_unlock


This does not look right. If you consider failing rename table from another
thread that comes right between Shared_unlock and Exclusive_lock, your
changes will be rolled back, even if you planned to commit actually. Maybe
we just have luck and server synchronizes exclusively anyway