3 ms·

Obviously, transaction may fail to be rolled back and leave dangling locks. Not sure about the specifics.

• marcosdumay 2y ago
  That's a bug in your database, not something you specify on your API.
  • thriftwy 2y ago
    What if it's a connection problem? DBs are normally remote. It's also OK to specify potential bug surface on your API.
    • thwarted 2y ago
      The bug being referred to isn't the connection problem, the bug is that in the event of a loss of communication with the client, the transaction isn't fully cleaned up, including the release of held locks, when the transaction enters an abortive state.
      • thriftwy 2y ago
        It often takes minutes to hours for a connection to be reset when one of its sides went away. So no, it's quite often that one side will get these exceptions while the other one is locked up for prolonged period of time.
• thwarted 2y ago
  I don't think that "leave dangling locks" is obviously a possibility from rollback failing. What's the method to clean up those locks? Rollback harder? Commit? If a transaction is ever aborted and there's a chance that locks specific to the transaction (MVCC locks necessary for transactional semantics) are still held then it would be safest to always issue this mythical "clean up locks" statement after every rollback attempt. The default final state of a transaction that is not explicitly committed (and even autocommit is still explicit) is that it is aborted, purely because the only way a transaction can be committed is by commiting it vs there are an infinite number of ways and reasons for the transactions to abort. If the rollback is successful or not there is logically no way that the state of the transaction after rollback being invoked is that the transaction is still usable for something.
• pmarreck 2y ago
  I unexpectedly shuddered at the term “dangling locks”