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

11–20 of 278 posts

Re: This Message Does Not Exist

#11

Post by marcosdumay »

thriftwy wrote: post #8
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…

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

That's a bug in your database, not something you specify on your API.

Re: This Message Does Not Exist

#12

Post by thriftwy »

marcosdumay wrote: post #11
thriftwy wrote: post #8

Earlier quoted context omitted.

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

That's a bug in your database, not something you specify on your API.

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

Re: This Message Does Not Exist

#13

Post by hyperman1 »

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…

I've seen this happen in Oracle using two phase commit, when the transaction coordinator drops dead before transmitting a commit or rollback decision. The transaction remained in doubt for months before someone noticed.

You can ask around and manually coordinate a decision, and tell the databasecwhat you decided.

Re: This Message Does Not Exist

#14

Post by thwarted »

thriftwy wrote: post #8
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…

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

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.

Re: This Message Does Not Exist

#15

Post by rzzzt » 

  > A returned value of 1 seems to say, "I'm here, but you can't use me." 
  > Strange as it may seem, that's exactly what is going on. A return code of 1
  > means we're not allowed to install the print spooler because interrupt 47 
  > is being used for some other purpose by some other interrupt handler. This
  > is a fascinating bit of business to contemplate.
https://archive.org/details/The_Peter_Norton_Programmers_Gui...

To me it sounds like that the service hogging interrupt 47 is saying that it can't be used for print spooling purposes.

Re: This Message Does Not Exist

#16

Post by thwarted »

hyperman1 wrote: post #13
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…

I've seen this happen in Oracle using two phase commit, when the transaction coordinator drops dead before transmitting a commit or rollback decision. The transaction remained in doubt for months before someone noticed. You can ask around and manually coordinate a decision, and tell the databasecwhat you decided.

Oh that's interesting, and probably manifests a bunch of issues related to storage and rollback segments being consumed with the transaction staying open for months.

But that's not the same thing as rollback failing (although it is the invocation of rollback failing) as neither rollback nor commit was fully issued and received, so it makes sense that the transaction would stay open (given that the database doesn't tie transactions to the a connection or a session, and for a two phase commit scenario I'd expect the transaction coordinator to "own" the transaction so it's lifetime isn't necessary tied to a session).

Re: This Message Does Not Exist

#18

Post by thwarted »

thriftwy wrote: post #12
marcosdumay wrote: post #11

Earlier quoted context omitted.

That's a bug in your database, not something you specify on your API.

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.

Re: This Message Does Not Exist

#20

Post by kelnos »

kazinator wrote: post #7

It's very easy. "This message does not exist" can be taken to be a false statement, without introducing any contradiction. It is not like "this message is false" (Liar's Paradox) or "this sentence has no proof" (Gödel's sentence). Unfortunately, just because "this message does not exist" is a false statement, contradicted by existential evidence, doesn't mean that the remaining claims next to it can be dismissed as f…

Perhaps not, but if one encounters a false statement, then it is reasonable to assume any following (and previous) statements are suspect as well.

Also I think you are missing the point. This is clearly written tongue-in-cheek. The author is being entirely rhetorical; they're not asking you to solve the apparent inconsistency. They just thought the error message was silly, and that working through it logically (as if each statement in the error message is true and correct) is a funny exercise.

Post reply on HN