Changes between Initial Version and Version 2 of Ticket #26933


Ignore:
Timestamp:
Jul 22, 2016, 2:07:23 PM (8 years ago)
Author:
Jensen Cochran
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #26933

    • Property Owner set to Jensen Cochran
    • Property Status newassigned
  • Ticket #26933 – Description

    initial v2  
    33I have written a patch for this that should mostly fix the issue.  Instead of assuming the database has locked the row,  I set a value in the spawned thread after select_for_update has ran and poll that value in the main thread.
    44
    5 However, there still has to be some kind of timeout as we cannot wait forever for the database to lock the row.  I have set that timeout at 5 seconds, and if the timeout occurs the test is skipped. Alternatively, I could fail if the timeout occurs, but this has potential to fail somewhat randomly as it is doing now.  If update_or_create were ever changed such that the locking behavior was removed, the test would fail so it should still serve its purpose.
     5However, there still has to be some kind of timeout as we cannot wait forever for the database to lock the row.  I have set that timeout at 0.5 seconds and have changed the thread/callable sleep time to 0.5 seconds as well to allow for more room for slow databases.  There is no reason to have the timeout be any longer than the thread sleep time, because once the main thread waits that long the assertion would pass no matter what anyway. If the timeout expires the test is skipped.
     6
     7Alternatively, I could fail if the timeout occurs, but this has potential to fail somewhat randomly as it is doing now. 
     8
     9If update_or_create were ever changed such that the locking behavior was removed, the test would fail as expected so it should still serve its purpose.
Back to Top