Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Message Does Not Exist

kmjn.org

Post reply on HN
Print view View original

21–30 of 278 posts

Re: This Message Does Not Exist

#24

Post by 4RealFreedom »

thwarted wrote: post #6

I've had similar philosophical thoughts about a transaction rollback. Consider this definition from go's database/sql package. func (tx *Tx) Rollback() error Rollback can fail, indicated as such by it can return an error. What are the cases where rollback could fail and what's the recovery mechanism? Does a failed rollback mean (logically) that the transaction is still open and uncommitted? But really, invoking rollb…

Not exactly the same but an engineer I was working with wasn't handling a failure case properly and leaving transactions open. It was reported that the DB would stop working after a certain amount of time. I knew transactions were hanging but I didn't understand why. I sat down with the engineer and QA trying to figure out the problem for well over a day. QA was running their test suite over and over. We started removing pieces one at a time until we found the problem.

Re: This Message Does Not Exist

#26

Post by thriftwy »

thwarted wrote: post #18
thriftwy wrote: post #12

Earlier quoted context omitted.

What if it's a connection problem? DBs are normally remote. It's also OK to specify potential bug surface on your API.

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.

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.

Re: This Message Does Not Exist

#27

Post by shpx »

thwarted wrote: post #6

I've had similar philosophical thoughts about a transaction rollback. Consider this definition from go's database/sql package. func (tx *Tx) Rollback() error Rollback can fail, indicated as such by it can return an error. What are the cases where rollback could fail and what's the recovery mechanism? Does a failed rollback mean (logically) that the transaction is still open and uncommitted? But really, invoking rollb…

Pending and rolled back are different transaction states. The former uses resources and locks and can prevent other transactions from happening.

Rolling back a transaction twice probably indicates an error in your program, which Go's API is giving you a chance to report to yourself.

Ultimately every network request can fail because of the Two Generals' Problem. Actually, every single operation on a computer can fail (as in, do something other than what you were promised or promised yourself it would do). Nothing in life is guaranteed, the environment is adversarial. The fact that we create machines that can be predicted with 0.00000000001% certainty and carve out a safe environment for them and feed them energy is not common and unnatural and all computers will also eventually succumb to entropy. The network is just where that is common enough that considering that another computer can die in our programs can be more useful than completely ignoring the possibility. This possibility is represented as a non-zero number called "error" in the Go API you've posted, so that you have the option of branching your program to a different execution path if the database you're communicating with stops existing or at least stops being reachable.

Post reply on HN