5 ms·

My experience is, single threaded execution and being able to replicate that with local data for each instance and remote lookup at a fine grained data level wh

My experience is, single threaded execution and being able to replicate that with local data for each instance and remote lookup at a fine grained data level when needed, is a more easier way to maintain the code. Cocurrency and all those synchronisation is damn hard to code and debug.

cle 7y ago
It has tradeoffs and can easily result in higher complexity, eg if you need a shared cache to minimize latency/memory. I like the attitude the article takes. To successfully use concurrency, you should understand the tools available to you and their tradeoffs so you can make the right decision for your requirements.
pjmlp 7y ago
When one has nice tooling like Visual Studio graphical debugging, not so much.
- tester756 7y ago
  Its it? https://marketplace.visualstudio.com/items?itemName=AdamWulkiewicz.GraphicalDebugging https://marketplace.visualstudio.com/items?itemName=AdamWulk...
tabtab 7y ago
In my opinion it's overhyped. I'll probably take point hits for claiming it, but so be it. Let the truth ring. Why copy techniques meant for Netflix and Facebook when your org or app is most likely 1/1000th their size. Phallic size jealousy at work. Most concurrent and parallel work can and should be done on a true-and-tried RDMBS for most orgs and apps. Use transactions/rollbacks properly and let the RDBMS manage most the grunt work instead of reinvent the wheel in app code. K.I.S.S. and use-the-right-tool-for-the-job.
- thallukrish 7y ago
  If you want extreme scale, most data in memory, such as a search engine processing millions of documents running data pipelines, then RDBMS isn't the way to go. For other MVC types, for a reasonable scale out, straight forward models with RDBMS should do.
  - tabtab 7y ago
    Note that existing RDBMS are gradually adding and improving their text search engines. Of course there will always be specialized situations that need dedicated high-end text search engines.

cle 7y ago

It has tradeoffs and can easily result in higher complexity, eg if you need a shared cache to minimize latency/memory. I like the attitude the article takes. To successfully use concurrency, you should understand the tools available to you and their tradeoffs so you can make the right decision for your requirements.

pjmlp 7y ago

When one has nice tooling like Visual Studio graphical debugging, not so much.

tester756 7y ago
Its it? https://marketplace.visualstudio.com/items?itemName=AdamWulkiewicz.GraphicalDebugging https://marketplace.visualstudio.com/items?itemName=AdamWulk...

tabtab 7y ago

In my opinion it's overhyped. I'll probably take point hits for claiming it, but so be it. Let the truth ring. Why copy techniques meant for Netflix and Facebook when your org or app is most likely 1/1000th their size. Phallic size jealousy at work. Most concurrent and parallel work can and should be done on a true-and-tried RDMBS for most orgs and apps. Use transactions/rollbacks properly and let the RDBMS manage most the grunt work instead of reinvent the wheel in app code. K.I.S.S. and use-the-right-tool-for-the-job.

thallukrish 7y ago
If you want extreme scale, most data in memory, such as a search engine processing millions of documents running data pipelines, then RDBMS isn't the way to go. For other MVC types, for a reasonable scale out, straight forward models with RDBMS should do.
- tabtab 7y ago
  Note that existing RDBMS are gradually adding and improving their text search engines. Of course there will always be specialized situations that need dedicated high-end text search engines.