Posted on

Java Concurrency and Multi-Threading

The Java platform was designed to support concurrent programming, with basic concurrency support in the Java programming language and the Java class libraries. How often do we think about concurrency while writing new code or while doing a code review with the team? A small bug could lead to endless hours of debugging applications for a production issue that is not easy to reproduce locally. 

Why do we need concurrent programming? We are in the age where we work with machines that are equipped with multi-core CPUs. The code you deliver should be optimized to run on such machines, utilizing the hardware to its fullest.  While designing a concurrent system, we should not interfere with other processes running on the CPU.  We want our application to run in its own black box without impacting other processes. These days we have multicore CPUs that can easily handle this but how was this done back in the days when the single-core was used?

Posted on

The Curious Case of Dead-End-Lock(Deadlock) | MySql

Usually, deadlocks are hard to debug, and often the main reason for the occurrence of deadlock is when a set of processes are in a wait state because each process is waiting for a resource that is held by some other waiting process. Therefore, all deadlocks involve conflicting resource needs by two or more processes.

Recently, in the Production system, we found a case wherein one of the API was getting a lot of failure of transactions due to deadlock. Strange thing was that it was not a total freeze deadlock of threads instead out of two conflicting transactions one was getting successfully completed.

Posted on

Deadlock in Databases

From databases perspective, a deadlock is a phenomenon that occurs when two transactions are blocking each other.

In the figure above, we have a classic deadlock situation. Transaction A (old man transaction) holds a lock to resource A (Dogs), but it doesn't release it until it will acquire a lock to resource B (Cats) that is currently locked by transaction B (young man transaction). In the same time, transaction B (young man transaction) holds a lock to resource B (Cats), but it doesn't release it until it will acquire a lock to resource A (Dogs) that is currently locked by transaction A (old man transaction).