diff options
author | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-21 16:29:53 -0800 |
---|---|---|
committer | Todd Gamblin <tgamblin@llnl.gov> | 2019-12-23 18:36:56 -0800 |
commit | bb517fdb8433ddb18b286c185403c7e1bc7eaae5 (patch) | |
tree | bd74c0dd1541d02382e0113a483cde1961d86405 /.travis.yml | |
parent | eb8fc4f3be7a1b5dd90313f0a8381bdaca346632 (diff) | |
download | spack-bb517fdb8433ddb18b286c185403c7e1bc7eaae5.tar.gz spack-bb517fdb8433ddb18b286c185403c7e1bc7eaae5.tar.bz2 spack-bb517fdb8433ddb18b286c185403c7e1bc7eaae5.tar.xz spack-bb517fdb8433ddb18b286c185403c7e1bc7eaae5.zip |
lock transactions: ensure that nested write transactions write
If a write transaction was nested inside a read transaction, it would not
write properly on release, e.g., in a sequence like this, inside our
`LockTransaction` class:
```
1 with spack.store.db.read_transaction():
2 with spack.store.db.write_transaction():
3 ...
4 with spack.store.db.read_transaction():
...
```
The WriteTransaction on line 2 had no way of knowing that its
`__exit__()` call was the last *write* in the nesting, and it would skip
calling its write function.
The `__exit__()` call of the `ReadTransaction` on line 1 wouldn't know
how to write, and the file would never be written.
The DB would be correct in memory, but the `ReadTransaction` on line 4
would re-read the whole DB assuming that other processes may have
modified it. Since the DB was never written, we got stale data.
- [x] Make `Lock.release_write()` return `True` whenever we release the
*last write* in a nest.
Diffstat (limited to '.travis.yml')
0 files changed, 0 insertions, 0 deletions