diff options
author | Matthew Draper <matthew@trebex.net> | 2017-04-11 08:10:24 +0930 |
---|---|---|
committer | Matthew Draper <matthew@trebex.net> | 2017-04-11 08:10:24 +0930 |
commit | e4c197c7698e204d0c74a2ece20adf831c2f9a8d (patch) | |
tree | f7c3ff10ac2c48f694a4645c42e56041b7299006 /railties | |
parent | 24ac36be7150f97ac0a61cf7cbe7d212097ef1a6 (diff) | |
download | rails-e4c197c7698e204d0c74a2ece20adf831c2f9a8d.tar.gz rails-e4c197c7698e204d0c74a2ece20adf831c2f9a8d.tar.bz2 rails-e4c197c7698e204d0c74a2ece20adf831c2f9a8d.zip |
Add comprehensive locking around DB transactions
Transactional-fixture using tests with racing threads and inter-thread
synchronisation inside transaction blocks will now deadlock... but
without this, they would just crash.
In 5.0, the threads didn't share a connection at all, so it would've
worked... but with the main thread inside the fixture transaction, they
wouldn't've been able to see each other.
So: as far as I can tell, the set of operations this "breaks" never had
a compelling use case. Meanwhile, it provides an increased level of
coherency to the operational feel of transactional fixtures.
If this does cause anyone problems, they're probably best off disabling
transactional fixtures on the affected tests, and managing transactions
themselves.
Diffstat (limited to 'railties')
0 files changed, 0 insertions, 0 deletions