[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Re: installing Oracle on Debian AMD64

Javier Bertoli wrote:
If you need to update a value in threads.post_count, that NEEDS to take in consideration what OTHER transactions do on table posts, then that code shouldn't be inside the transaction.
No, that's not true. We still want our operation to be performed all at once, or not at all.. That's what a transaction does.

 I think that's wrong, because
transactions are there to provide, among other things, "a snapshot" of the DB to an atomic operation.
That is correct.

 And as such, you are not supposed to know
what other transactions are doing at the same time that yours.
No, that's not true. That's only true if you're running in isolation level SERIALIZED. In any other transaction level, that's not a safe assumption to make.

It's just a reality of concurrent processing.

You're attempting to make the argument because two threads of execution are making an update against a "snapshot" of the the same set of data, the left hand doesn't need to know what the right hand is doing.

That's only true iff either of these assumptions are true:
1. The threads don't really run concurrently.
2. The snapshots are never combined back into the same datasource.

Neither is normally true for a SQL RDMBS. However, the fact neither is true doesn't allow you to turn around and conclude that transactions are evil and/or unnecessary here. In fact, you didn't even attempt to, just stated that they are, so I really think you're actually in agreement with me, you just may not realize it. ;)

If the update to the postcount fails, I still want the inserted post removed. I still want an atomic context, I just have to be aware of the fact other atomic contexts are accessing the data in a parallel fashion.

That doesn't mean I shouldn't take the context away.

If threads.post_count needs to be updated CONSIDERING what ALL the transactions on table posts are doing, I think you should be using a POST INSERT TRIGGER on posts, that takes care of the issue of updating threads.post_count.
Yes, I probably would. That wasn't the point of the example, and not every case where such an update is being done can be resolved by triggers, nor can a trigger be always used: perhaps the update is needed within the scope of the transaction, then a trigger is completely inappropriate.


Reply to: