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.
Adam
Reply to: