)]}'
{"specs/mitaka/approved/resource-providers.rst":[{"author":{"_account_id":15648,"name":"Yingxin","email":"yingxin.cheng@intel.com","username":"Yingxin"},"change_message_id":"0fe63f8779830d29bf5d083dbea1cb399c40e3c0","unresolved":false,"context_lines":[{"line_number":239,"context_line":"        IF $ROWS_AFFECTED \u003d\u003d 0:"},{"line_number":240,"context_line":"            ROLLBACK TRANSACTION;"},{"line_number":241,"context_line":"            GO TO deadlock_retry;"},{"line_number":242,"context_line":"        COMMIT TRANSACTION;"},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Alternatives"},{"line_number":245,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bae84128_8d3d14be","line":242,"updated":"2016-02-25 03:17:25.000000000","message":"It looks like a much faster version of retry if the resource claim fails. A nice solution to make resource claim atomic in the db. So +1 for it.\n\n\n######\nSomething off-subject : )\n\nThe cause of claim failure is different between db claim and resource tracker claim. In db claim(according to this implementation), a claim will be failed because the origin condition is changed by other threads during the transaction. In resource tracker in-memory claim, the claim process can be easily protected by lightweight locks, so a failed claim will actually be caused by the truth \"the host will end up with more resources consumed than can actually fit\" (excluded those shared resources).\n\nThis is a new interesting point that I think the resource tracker claim will be faster than the db claim in its manageable resources.","commit_id":"7d18e806d054e683b4965a9b2c1fb1150bd33270"}]}