Ayende @ Rahien

Scooletz commented on When race conditions & unbounded result sets are actually the solution – the resolution

Sat, 23 Apr 2011 05:06:05 GMT

Having the numbers: 10^5 requests to perform, 1s - time of a single request, the solution simply begs for using some kind of a dispatcher moving the applications from "I am a single instance of Windows serwice" rather to "I use some bus (MassTransit, NServiceBus) to dispatch all of asynchronous work".

Brian commented on When race conditions & unbounded result sets are actually the solution – the resolution

Fri, 22 Apr 2011 15:34:42 GMT

Maybe I'm underthinking this. Why not just use the TPL? int numConcurentRequests = 25; Subscription[] subscriptions = session.Query s.NextCharge < DateTime.Now).ToArray(); numConcurentRequests = numConcurentRequests > subscriptions.Count() ? subscriptions.Count() : numConcurentRequests; Task[] tasks = new Task[numConcurentRequests]; for (int i = 0; i < subscriptions.Count(); i++) { if (i % numConcurentRequests == 0 && i >= numConcurentRequests) Task.WaitAll(tasks); tasks[i % numConcurentRequests] = Task.Factory.StartNew( () => { subscriptions[i].ChargeAccount(); } ); } >

Frank Quednau commented on When race conditions & unbounded result sets are actually the solution – the resolution

Fri, 22 Apr 2011 13:49:20 GMT

Not really a tech thing, but I'd consider prioritizing billing operations. For example going for larger outstanding bills first and every x weeks going for small amounts (because, if the business runs well, they may never be charged). Also it could be considered whether it is feasible to split the bill. That way, if you don't get the full amount you take what is available, and call the transaction xyz pt.1 Additionally it may be worth to throw more money at the intelligence you deploy with regards to when the accounts are filled. Outwitting others in that respect should reduce the need to actually race for the money.

ammarmar commented on When race conditions & unbounded result sets are actually the solution – the resolution

Fri, 22 Apr 2011 11:17:19 GMT

Queues are nice. We use MSMQ for similar application (just not dealing with money :). I like the way you can always pause processing and restart it later (fine granularity). With introducing of error queues you also get an opportunity to push failed requests to it and get back to them later. Sometimes, when the error is e.g. network-related, fixing it is as simple as movine the message from error queue back to the regular one.