When a transaction conflict occurs, right now the exception is just a name of the conflict. We can provide extra metadata about the transaction to aid in debugging.
I tried to see if rocksdb provides additional information for the transaction, such as what keys are actually outdated and is causing the conflict, however it does not appear to be part of the transaction interface.
I reckon it should exist somewhere, but I can't really find it.
Regardless, we could provide additional information on the keys that are being updated all the keys that are put and del applied as well as keys that were read under get. Also what locks the transaction was locking at that point. All of this can be applied in the data property of the exception.
The transaction message would ideally indicate exactly which keys are under conflict, but in the mean time, the transaction ID could be useful.
Should create a issue upstream on rocksdb to ask how to actually acquire the keys under conflict, or ask on SO if somebody knows.
Specification
When a transaction conflict occurs, right now the exception is just a name of the conflict. We can provide extra metadata about the transaction to aid in debugging.
I tried to see if rocksdb provides additional information for the transaction, such as what keys are actually outdated and is causing the conflict, however it does not appear to be part of the transaction interface.
I reckon it should exist somewhere, but I can't really find it.
Regardless, we could provide additional information on the keys that are being updated all the keys that are
putanddelapplied as well as keys that were read underget. Also what locks the transaction was locking at that point. All of this can be applied in thedataproperty of the exception.The transaction message would ideally indicate exactly which keys are under conflict, but in the mean time, the transaction ID could be useful.
Should create a issue upstream on rocksdb to ask how to actually acquire the keys under conflict, or ask on SO if somebody knows.
Tasks