Bug 1283062

Description of problem:

Updates to pool are not bound to transaction in any way. Any failure will block further processing and revert db. The only thing, which does not revert, and we do not even know how to do it(!), is macPool alteration. That means change pool settings, acquiring and returning macs. If that happens, some MACs may become erroneously marked as used or unused.

When updating pool ranges settings we currently use this strategy: do pool modification as a last action and 'hope' that this operation itself will not fail. If it will fail there, for any reason (incl. java.lang.Error)., in memory pool become corrupted, however it's quite unlikely that this will happen.


To fix this issue for acquiring/releasing macs we have to examine all usages and fix them some how, or better, we have to bound these actions on mac pool to current transaction and revert them, if that transaction is reverted. 

1) when updating pool, we must support 'undo'. That can be achieved via a) creating new instances and once they're ready swap them for original one. b) creating chain of instances representing performed actions — journal — and replay it back. Both will require new methods on pool.
2) all code acquiring / releasing mac from/to pool needs 'onrollback listener handler'. One possible solution would be, that pool itself remembers to/from whom he given/got certain mac and in which transaction. Using transaction completion listener he'd clear that list or reverted performed action. This will have to also grant, that released mac isn't actually available until COMMIT, and acquired mac won't be available until rollback even if transaction requiring it wasn't committed yet.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: