An Introduction to Ruby's 'Fibers'

Image Source: are fibers? Fibers are workers, they run code & keep track of their progress. They are a concurrency mechanism like threads but are contrasting in nature when compared with threads. The control flow of a thread can get interrupted at any time and another thread can take over. With fiber, the control only switches when we explicitly tell it to. In this article, we will dive deeper to understand this difference and how to implement Fibers. First things first, the difference between #fibers and #threads Fibers are light-weight and they eat much less memory

Optimistic vs. Pessimistic locking in Rails

While performing concurrent operations, a database must ensure data integrity. ACID compliant relational database ensures this data integrity through its locking mechanism. ACID = Atomicity, Consistency, Isolation, Durability Locks can be at the database, table, page, or row level. Here is a beginner's guide to database locking in PostgreSQL. In this article, let's see how Rails provides a mechanism for optimistic locking on ActiveRecord models. However, before we proceed, let us first understand the basics of optimistic and pessimistic locking. What is optimistic locking? Let's take an example of two admin users, Mohan and Ritesh, managing the product inventory in their

Issue with Unicorn that might occur with multiple requests for same data.

How does Unicorn works out? Unicorn works in cluster wherein it queues requests to multiple workers. Whenever the Unicorn master starts, it loads the app into its memory and handles to serve the requests to its workers. Here is a link which will elaborate the architecture for Unicorn in a nutshell: [Unicorn Architecture(][1] This is one of the good architecture that helps to distribute requests to provide load balancing. At the same time, there might occur an issue with Data Transaction (Concurrency). Would like to give a small scenario that created a issue in