diff options
author | Eugene Kenny <elkenny@gmail.com> | 2018-05-16 22:40:20 +0100 |
---|---|---|
committer | Eugene Kenny <elkenny@gmail.com> | 2018-05-19 01:34:16 +0100 |
commit | 5359428a142239578b4d1dfb43dd8c417ab57b5c (patch) | |
tree | cca7cff257f4d47ec7a0a6c02ccaec4835dc5687 /activejob/test | |
parent | 1efbc634b5707cfca1bec0cf39f90520396a979b (diff) | |
download | rails-5359428a142239578b4d1dfb43dd8c417ab57b5c.tar.gz rails-5359428a142239578b4d1dfb43dd8c417ab57b5c.tar.bz2 rails-5359428a142239578b4d1dfb43dd8c417ab57b5c.zip |
Finalize transaction record state after real transaction
After a real (non-savepoint) transaction has committed or rolled back,
the original persistence-related state for all records modified in that
transaction is discarded or restored, respectively.
When the model has transactional callbacks, this happens synchronously
in the `committed!` or `rolled_back!` methods; otherwise, it happens
lazily the next time the record's persistence-related state is accessed.
The synchronous code path always finalizes the state of the record, but
the lazy code path only pops one "level" from the transaction counter,
assuming it will always reach zero immediately after a real transaction.
As the test cases included here demonstrate, that isn't always the case.
By using the same logic as the synchronous code path, we ensure that the
record's state is always updated after a real transaction has finished.
Diffstat (limited to 'activejob/test')
0 files changed, 0 insertions, 0 deletions