http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660[rhino-tools.svn.sourceforge.net/.../rhino-dht](https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-dht)http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment18http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment18Mon, 02 Feb 2009 21:57:30 GMTHow do we download your DHT? Thanks http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment17http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment17Mon, 02 Feb 2009 21:50:01 GMTAyende, I just want to add some comments which could help me to better understand the whole picture. #1 All unresolved co-existing states should be treated as events occurred at the same time. If developer still needs to know the real order of the unresolved events (who knows the real tasks where Rhino DHT could be used?) he could add special properties to the message type. The property could be used to resolve the order of the unresolved messages on the client side. #2 If developer still needs to have locking mechanism, could it be implemented using current approach? http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment16http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment16Mon, 26 Jan 2009 16:55:13 GMTOfer, I recommend that you would read about the CAP theorem. There is no general case in this situation. What you want to be able to do is to select which two you want to use at any given point in time, consistency, availability or partition. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment15http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment15Sat, 24 Jan 2009 20:16:03 GMTAyende, If you can take those assumptions then I agree - your method of dealing with concurrency must be super-fast in performance. I was talking about the general case. Stephan, I think you can decide on whatever policy that suits you, as long as you can enforce it. Cutting the call is certainly an option. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment14http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment14Sat, 24 Jan 2009 20:13:46 GMTOfer, how do you handle the customer being at say $95 overdrawn, and the limit is $100 before she aparently gets blocked, say she is charged $1 a minute, does she get cut off after the 5 minutes? how does policy of complex systems like this work? seems to me you cant really ensure that kinda policy at this level.. I would of thought you could avoid a lot of the billing trouble by not involving cost information at this stage.. just recording all the billable things then working out at a specific moment in time (end of month say) what the costs would be when you have the complete picture. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment13http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment13Sat, 24 Jan 2009 17:58:59 GMTOfer, Not quite, this is valid even if you have context and interactions. The merge tend to happen shortly after a conflict occurs, usually, it is resolved within a few hundreds milliseconds of its occuring. You can usually tolerate an inconsistent state for that time frame. Even if you rejected a call that should have been made, the user can try calling back again immediately and get a connection. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment12http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment12Sat, 24 Jan 2009 17:51:16 GMTI think that your solution works under the following assumptions: 1. The concurrent events have no context - they can happen regardless of state. 2. The concurrent events have no interactions and there is no importance to their order in time (this is kind of a special case of 1). Why is it important? Lets say number 1 doesn't hold. Lets say we do not allow a user to call once he has a dept of 100$. If he is at 94$, and he does an sms and a 1 minute call concurrently, he should be 94+2+5=101$ in dept. In this situation we shouldn't have let the user make both the call and the sms. We will discover this too late - on Merge() and at that point we will be in an illegal system state. I liked your general direction for solving concurrency issues. I wonder if you have any other way to solve this... except locking mechanisms! :) http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment11http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment11Sat, 24 Jan 2009 11:23:01 GMTjdn, Thanks, fixed. It is a number that is a numeric representation of a GUID. I didn't want to put a real guid because non one can just read them http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment10http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment10Fri, 23 Jan 2009 18:02:25 GMTVersion 46 is missing the 2 min call that costs $10 (332-843...btw, what does that number represent?), and caused the initial overdraft charge, isn't it? http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment9http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment9Fri, 23 Jan 2009 16:23:30 GMT_That_ was intentional :-) http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment8http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment8Fri, 23 Jan 2009 15:18:07 GMTI don't know if you're making a joke or a typo but "writing parallel hard be is" is very funny in pirate English and basically sums up my feelings about the subject after reading your DHT posts. Arrghh. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment7http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment7Fri, 23 Jan 2009 15:04:10 GMTThat is a bug in the code, sorry. Fixed it http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment6http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment6Fri, 23 Jan 2009 14:00:25 GMTIn the merge you say ' if the merged state has a balance item with the same id, then add it ', is this correct? I'm not sure how the first loop would do anything because a new BillingStatementState wouldn't contain anything right? http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment5http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment5Fri, 23 Jan 2009 13:47:48 GMTThat is why you should not blog about complex topics after midnight. There were numerous errors in the diagrams. All should be fixed now http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment4http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment4Fri, 23 Jan 2009 13:33:38 GMTmeowth, This is something that the client library will handle. Check and see Rhino Service Bus' way of doing this. http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment3http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment3Fri, 23 Jan 2009 13:32:37 GMTDoes the merge ability planned to be embedded into DHT or to be implemented in a separate scenatio/saga? http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment2http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment2Fri, 23 Jan 2009 13:18:18 GMTWhy 44th version (the green one) also contains that 2min call? Shouldn't that call be 43rd version's exclusive item? The purple 44th version (the one with +20 balance) should probably be numbered 45. And here again this strange 2min call from v43. Right? http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment1http://ayende.com/3827/rhino-dht-concurrency-handling-example-the-phone-billing-system#comment1Fri, 23 Jan 2009 11:01:31 GMT