On 14/03/14 11:08, Alexei Kornienko wrote: > On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:
[snip] >> OpenStack is a big, distributed system of multiple databases that >> sometimes rely on each other and cross-reference their records. It's not >> uncommon to have some long-running operation started, that uses some >> data, and then, in the middle of its execution, have that data deleted. >> With soft delete, that's not a problem -- the operation can continue >> safely and proceed as scheduled, with the data it was started with in >> the first place -- it still has access to the deleted records as if >> nothing happened. You simply won't be able to schedule another operation >> like that with the same data, because it has been soft-deleted and won't >> pass the validation at the beginning (or even won't appear in the UI or >> CLI). This solves a lot of race conditions, error handling, additional >> checks to make sure the record still exists, etc. > > 1) Operation in SQL are working in transactions so deleted records will > be visible for other clients until transaction commit. > > 2) If someone inside the same transaction will try to use record that is > already deleted it's definitely an error in our code and should be fixed. > I don't think that such use case can be used as an argument to keep soft > deleted records. Yes, that's why it works just fine when you have a single database in one place. You can have locks, transactions, cascading operations and all this stuff, and you have a guarantee that you are always in a consistent state, unless there is a horrible bug. OpenStack, however, is not a single database. There is no system-wide solution for locks, transactions or rollbacks. Every time you reference anything across databases, you are going to run into this problem. -- Radomir Dopieralski _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
