On Jul 26, 2011, at 5:56 PM, Christopher Browne wrote:
>> I'm assuming that the issue here is that multiple backends could be connected to the same database, and we don't
wantall of them to try to actually do the updates, only the first one that discovers the change. If that's the problem
youforesee then perhaps it's a non-issue... if each backend only updates things that have actually changed, and they do
thatwith race-free 'merge' logic, then only the first backend to attempt the update would end up finding actual work to
do.
>>
>> Or are you seeing a problem I'm missing?
>
> What if 4 backends concurrently are the "first ones" to try to
> simultaneously add "South America/Ruritania", and...
>
> 1. Connection #1 came in 'first', but rolls back its transaction.
> 2. Connection #2 came in 'second', and also winds up rolling back its
> transaction because the connection fails due to a network problem.
> 3. Connection #3 actually completes. But doesn't commit until after #4.
> 4. Connection #4 started last, but turns out to COMMIT first.
Ugh, I didn't realize that a reload would take effect in the middle of a transaction. That certainly kills what I
proposed.
Though, now I'm wondering why this info would need to be in every database anyway... certainly this should be treated
asglobal data, and if that's the case then only one process needs to update it. Though I'm not sure if it's possible
forglobal data to be ACID.
Anyway, rather than continue this on-list, I'm going to get Alvaro to think about it in more detail and see what he
comesup with.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net