Forem: Faiz Ahmad

Understanding Optimistic Locking: Handling Conflicts in Concurrent Systems

Faiz Ahmad — Mon, 09 Sep 2024 03:42:44 +0000

In modern applications, where multiple users might try to access or update the same data simultaneously, ensuring data consistency while allowing concurrency is critical. One common way to manage this is through optimistic locking. This article will explain optimistic locking, walk through an example scenario, and explore when it’s appropriate to use and when it’s not.

What is Optimistic Locking?

Optimistic locking is a concurrency control mechanism used to manage simultaneous updates to the same data in a database. It assumes that conflicts are rare and allows multiple users to proceed with their operations without locking the data. At the time of committing the changes, optimistic locking checks if any conflict has occurred (i.e., if the data was modified by another user). If a conflict is detected, the transaction fails, and the user must retry.

Unlike pessimistic locking, which prevents conflicts by locking data during a transaction, optimistic locking allows changes to proceed concurrently but checks for conflicts only when changes are committed.

Use Case for Optimistic Locking

Optimistic locking is ideal in scenarios where conflicts are unlikely but must still be handled gracefully when they occur. This makes it useful in collaborative applications, such as:

Document editing systems (e.g., wikis or blog posts), where multiple users may edit the same document.
Shared shopping carts, where multiple users might add or update items simultaneously.
Content management systems (CMS), where users may update posts or entries without frequent overlapping changes.

Example Scenario: Conflict Detection with Optimistic Locking

Let’s explore how optimistic locking works in a database by simulating two users trying to update the same document simultaneously. We’ll use MySQL commands to illustrate this scenario.

Step 1: Initial Setup

Assume we have a documents table with a version number that tracks changes:

CREATE TABLE documents (
    id INT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(255),
    content TEXT,
    version INT DEFAULT 1  -- Version number for optimistic locking
);

We insert an initial document:

INSERT INTO documents (title, content) VALUES ('My First Document', 'This is the initial content.');

Now, both users will attempt to modify the document simultaneously.

Step 2: Simulating Two Users Editing the Document

User A (First Transaction)

Start a Transaction:

   START TRANSACTION;

Read the Document:

   SELECT title, content, version FROM documents WHERE id = 1;

User A sees the content and the version of the document (version = 1).

Update the Document:

   UPDATE documents
   SET content = 'This is User A’s updated content.', version = version + 1
   WHERE id = 1 AND version = 1;

This update checks that the document’s version is still 1. If so, it updates the content and increments the version number.

Commit the Transaction:

   COMMIT;

Now, User A has successfully updated the content, and the version number of the document is incremented to 2.

User B (Second Transaction)

Start a Transaction:

   START TRANSACTION;

Read the Document:

   SELECT title, content, version FROM documents WHERE id = 1;

User B sees the same version (1), since User A has not yet committed.

Attempt to Update the Document:

   UPDATE documents
   SET content = 'This is User B’s updated content.', version = version + 1
   WHERE id = 1 AND version = 1;

Commit the Transaction:

   COMMIT;

Step 3: Conflict Detection

When User B tries to commit the update, the database checks the version of the document.
Since User A has already committed their changes and incremented the version number to 2, the condition WHERE version = 1 fails.
User B's transaction is not completed, and a conflict is detected.

In this case, User B can either retry the operation after reloading the updated data or handle the conflict by informing the user.

When Not to Use Optimistic Locking

While optimistic locking is great for collaborative environments with low chances of conflicts, there are scenarios where it’s not the best fit:

High Contention Scenarios:
In systems where multiple users frequently update the same data, conflicts might be too common, causing frequent transaction failures and retries. In such cases, pessimistic locking is a better fit because it prevents conflicts from happening at all by locking data upfront.
Real-Time Systems:
Applications like financial systems or high-frequency trading platforms, where data integrity and timing are critical, often use pessimistic locking or other concurrency controls to ensure consistency without waiting for conflicts to be detected.
Latency-Sensitive Environments:
In situations where retrying operations due to conflicts introduces unacceptable latency, optimistic locking might lead to a poor user experience. In these cases, pessimistic locking or other locking strategies might be more suitable.

Conclusion

Optimistic locking is a powerful mechanism for handling concurrent transactions, allowing multiple users to work on the same data without locking it, but still detecting conflicts when they occur. It’s especially useful in collaborative environments where the likelihood of conflicts is low, but it may not be ideal for high-contention systems where conflicts are frequent.

Have you used optimistic locking in your projects? What has your experience been? Share your thoughts in the comments below, and don’t forget to like, share, and provide your feedback on this article!

Handling Date and Timezone Conversions: Why Proper UTC Conversion Matters

Faiz Ahmad — Sun, 08 Sep 2024 07:39:59 +0000

While retrieving data for a selected date range, we noticed that our calculation was off by some margin. However, when we decreased the date by one day, the data matched exactly!

Hmmm… There might be an issue with how the date is being handled in our code. Perhaps the timezone is not being handled correctly—and yes, I was right!

When building applications that involve users from different timezones, handling dates properly can be tricky. Storing dates in UTC is a common best practice to ensure consistency, but things can get complicated when users input dates in their local timezone, especially during filtering and querying.

Developers often resort to the native JavaScript Date object for handling these conversions. However, this approach can lead to inconsistencies across environments, such as Node.js vs. browser consoles like Chrome. In this article, we’ll explore why handling date and timezone conversions properly is crucial, how Luxon can make this process easier, and why relying on the native JavaScript Date object can lead to inconsistencies.

The Problem: UTC Storage vs. Local Time Filtering

When dates are stored in UTC, they represent a global standard that eliminates the ambiguity caused by timezones. However, users typically think in terms of their local timezone. This discrepancy becomes evident when users try to filter records by date using local time inputs.

Let’s look at an example where a user’s local time inputs could lead to missed records if not handled properly.

Example Scenario: A User in the GMT-7 Timezone

Imagine a user in the GMT-7 timezone (Pacific Daylight Time). On September 5th, 2024, they create a record at 10:00 PM in their local time. Here’s what happens behind the scenes:

September 5th, 2024, 10:00 PM GMT-7 is converted to September 6th, 2024, 05:00 AM UTC and stored in the database as such.
The user, however, perceives that they created this record on September 5th.

The Filter Mismatch

Now, suppose the user wants to query all records created on September 5th. They input the date September 5th, 2024, expecting to retrieve their record. However, if the system compares the input date directly to the stored UTC date without adjusting for timezone differences, the user will miss the record. Why?

The record was saved in the database as September 6th (UTC).
The user filters for September 5th (their local time), but the system compares this against UTC, resulting in no match.

JavaScript `Date` Object: Inconsistencies Across Environments

The following example code demonstrates a common problem when using the native JavaScript Date object for handling date and time conversions, particularly across different environments such as Node.js and the browser (e.g., Chrome console).

Example Code:

function convertToUtcStartOfDay(isoString) {
  // Step 1: Parse the ISO string into a Date object
  let localDate = new Date(isoString);

  // Step 2: Set the time to the start of the day (00:00:00) in local time zone
  localDate.setHours(0, 0, 0, 0);

  // Step 3: Get the UTC time using toISOString() – it converts local time to UTC
  let utcStartOfDay = localDate.toISOString();

  return utcStartOfDay; // This will be in UTC
}

// Example usage:
let frontendDate = "2023-08-22T00:00:00+05:30"; // ISO string with timezone offset
let startOfDayUtc = convertToUtcStartOfDay(frontendDate);

console.log(startOfDayUtc); // Expected output: "2023-08-21T18:30:00.000Z"

In this example, the user inputs the date "2023-08-22T00:00:00+05:30" (from a GMT+5:30 timezone). The Date object should convert it to the start of the day in UTC, but when executed:

In Node.js, the output is 2023-08-21T00:00:00.000Z - Wrong
In Chrome's console, the output is 2023-08-21T18:30:00.000Z - Correct

This discrepancy can cause unpredictable results depending on where the code is executed. This behavior makes the Date object unreliable for consistent date handling across different environments.

Using Luxon for Accurate Date Handling

To solve this problem, it's important to use a library like Luxon that provides consistent behavior across environments. Luxon helps you convert the user’s local input to the proper start and end of the day in their timezone, and then convert those times to UTC for accurate database queries.

Here’s an example using Luxon to handle this:

const { DateTime } = require('luxon');

// Example user input date in ISO string with timezone information from the frontend
const userInputDate = "2023-08-22T00:00:00+05:30"; // ISO string sent by frontend

// Step 1: Parse the ISO string to get the user's local time
const userLocalDate = DateTime.fromISO(userInputDate);

// Step 2: Convert this date to start of the day and end of the day in the user's local timezone
const startOfDayLocal = userLocalDate.startOf('day'); // start of the day in the user's timezone
const endOfDayLocal = userLocalDate.endOf('day'); // end of the day in the user's timezone

// Step 3: Convert these local start and end times to UTC
const startOfDayUtc = startOfDayLocal.toUTC().toJSDate(); // start of the day in UTC
const endOfDayUtc = endOfDayLocal.toUTC().toJSDate(); // end of the day in UTC

// Step 4: Query the database using the UTC range
db.records.find({
  createdAt: {
    $gte: startOfDayUtc,
    $lte: endOfDayUtc
  }
});

Why Luxon is Better than JavaScript `Date` Objects

Handling date and timezone conversions directly with the native JavaScript Date object can lead to inconsistencies like the one demonstrated above. Here are a few reasons why Luxon is a better alternative:

Consistency Across Environments: Luxon provides consistent behavior whether the code is running in Node.js or the browser (e.g., Chrome console). This eliminates the discrepancies that arise from using the Date object in different environments.
Built-in Timezone Support: Luxon makes it easy to convert between timezones, while the Date object doesn’t offer robust support for timezone manipulation.
Simple Date Manipulation: Setting the start or end of a day in the user's local timezone and converting it to UTC is a common task in global applications. Luxon simplifies this process with its intuitive API, while Date requires complex manual handling.

Conclusion

Handling date and timezone conversions properly is crucial for building reliable, user-friendly applications. If developers fail to account for timezone differences when filtering records, users may miss important data—leading to confusion and potentially critical errors.

Using Luxon instead of the native JavaScript Date object provides consistency, better timezone handling, and easier manipulation of dates. This allows developers to create a seamless experience for users across timezones, ensuring that queries work as expected, and no records are missed during filtering.

In global applications, accurate and reliable date handling is key to delivering a high-quality experience to users, regardless of their timezone.

Final Thoughts

Have you ever encountered a similar situation where date and timezone handling caused unexpected results in your application? How did you address it? I’d love to hear about your experiences, feedback, or any questions or concerns you might have. Feel free to share them in the comments section below. If you found this article helpful, please like and share it with others who might benefit from it!

Forem: Faiz Ahmad

Understanding Optimistic Locking: Handling Conflicts in Concurrent Systems

What is Optimistic Locking?

Use Case for Optimistic Locking

Example Scenario: Conflict Detection with Optimistic Locking

Step 1: Initial Setup

Step 2: Simulating Two Users Editing the Document

User A (First Transaction)

User B (Second Transaction)

Step 3: Conflict Detection

When Not to Use Optimistic Locking

Conclusion

Handling Date and Timezone Conversions: Why Proper UTC Conversion Matters

The Problem: UTC Storage vs. Local Time Filtering

Example Scenario: A User in the GMT-7 Timezone

The Filter Mismatch

JavaScript Date Object: Inconsistencies Across Environments

Example Code:

Using Luxon for Accurate Date Handling

Why Luxon is Better than JavaScript Date Objects

Conclusion

JavaScript `Date` Object: Inconsistencies Across Environments

Why Luxon is Better than JavaScript `Date` Objects