To control concurrency in applications, we should implement only the best approaches because a good developer avoids unnecessary complexity to an application.
Join the DZone community and get the full member experience. Imagine in our application we need to update a value that is shared between all requests. It means we should control concurrent requests for manipulating this shared resource. Somehow we should serialize the access to resources. In our example, we keep this value in the Redis cache for reducing latency. To make our example more clear, imagine we have a contribution amount that is updated by each request. This value should be plus the contribution amount of incoming requests. Let’s demonstrate our scenario with graphic symbols for better understanding. We have an application that has subscribed to a RabbitMQ queue. In the simplest model, we receive a message from the queue and update our contribution amount in Redis in synchronized mode, which means the application process requests one by one. Everything looks fine. We may encounter two problems: 1- What if the application uses async processing to process messages from the queue? 2- What if we horizontally scale the application, means running several instances of the application? In these two cases, we will receive more than one request, and somehow the concurrency should be controlled, otherwise, we will face Race conditions in Redis and the contribution value is not valid anymore. The first solution which can be brought up is to use an internal lock object for controlling the critical point. This solution works well for the first problem. But what about the second one? In the case of horizontal scaling, the internal lock just works in the scope of one instance, we should find a control mechanism outside of the application scope. 1 – Actor systems like Akka or Orleans(. Net) 2- Distributed lock manager (DLM) 3- Add your solutions here In my point of view if your application does not have to deal with lots of concurrent scenarios like what I’ve mentioned, using a DLM is better for sake of simplicity. Because implementing actor systems bring more complexity to your projects. But if you have an application with lots of critical points in which concurrency should be controlled, I also prefer to use actor systems.
