gistfile1.txt

15:38 <aphyr> When you're designing systems where concurrent writes could 
cause minor corruption (links to missing objects, for example), 
do you try to rigorously prevent them at modification time, or 
use sweep-and-repair jobs periodically? 

15:39 <drev1> depends on the application 

15:43 <benblack> aphyr: mostly i design to avoid that ever happening. 

15:44 <* ericflo> is interested in this topic 

15:44 <Damm|lunch> ericflo, who isn't? 

15:44 <Damm|lunch> :) 

15:44 <Damm|lunch> even got my attention 

15:45 <aphyr> benblack: yeah, I'm just having trouble with concurrent 
writes with things like indices. Haven't had to solve this problem 
without locks before. 

15:46 <aphyr> i.e. write a user (keyed by, say, username) and an email 
address pointing to that user. 

15:47 <aphyr> If you modify the user's email address, you need to update 
both the user record and the email pointer 

15:47 <aphyr> But if another modification is running at the same time, 
you could fail to win the pointer update and need to back out your changes. 

15:47 <aphyr> So I thought "Oh, I'll use siblings and remove the version I created" 

15:48 <aphyr> Which I suppose is valid unless three-way contention happens, 
or a client crashes before finishing its work. 

15:48 <aphyr> In reality, I'm OK with a probabilistic, lossy solution 
for this dataset, but I'd like to know how to do it perfectly. :)

15:49 <benblack> eventual consistency made visible 

15:49 <benblack> 3-way contention -> 3 siblings 

15:49 <benblack> you keep detecting and resolving siblings 

15:50 <aphyr> Can you write back multiple siblings, or just one? 

15:50 <benblack> once there is no contention, there are no more siblings 

15:50 <benblack> no? 

15:50 <benblack> you write back 1 

15:50 <aphyr> So if there are three siblings, and I only know that I 
created *one* of those, that leaves two to choose between. 

15:50 <benblack> or you create a 4th that subsumes all the others 

15:51 <aphyr> But there is no way to inform the other clients that their 
changes have failed, then. 

15:52 <aphyr> Maybe I could detect the presence of siblings after my 
write, abort the entire process, and try again after a random delay... 

15:52 <benblack> i'm suggesting the others don't "fail" 

15:52 <benblack> you can merge 

15:53 <aphyr> I can't in the case of conflicting values for the 
same field. 

15:53 <aphyr> For instance, two clients setting different email 
addresses on a user. 

15:53 <benblack> ask yourself why that would happen 

15:54 <aphyr> Haha, you're right, it's probably not going to happen.
Still curious. 

15:55 <benblack> probably not going to happen is one answer 

15:55 <benblack> i'm asking in what legitimate case that would happen 

15:55 <benblack> because if there is no such case 

15:55 <benblack> stomp it 

15:55 <benblack> pick one of the updates and use it