Blog

Jon Clausen

February 16, 2024

Spread the word


Share your thoughts

v3.3.0 released!

 

We are very excited to bring you another release for our Redis Lucee Extension. The most significant feature in this release is the addition of the <cfRedisLock>/redisLock{} tag, which allows you perform a lock across all instances in a cluster.

When running in a clustered environment, it is often desirable that a specific action or assignment be performed by one user. Take, for example, the following code:

var customer = customerService.get( customerId );
var hotelRoom = hotelService.getRoom( roomNumber );
reservationService.reserve( hotelRoom, customer );

In a clustered environment, we would want to prevent the same same hotel room from potentially being reserved by two separate guests ( because: awkward....! )

With the redisLock tag, we now have the ability to prevent concurrent attempts to perform the same action by two users in the system. The method signature for both redisLock and cfRedisLock is as follows:

redisLock
    name="[ the name of the lock to place ]"
    cache="[ the configured redis cache to use for locking ]"
    throwOnTimeout="[ Defaults to true, whether to throw on failure to lock]"
    expires="[the max duration of the lock entry to exists in seconds - default 60s]"
    timeout="[the max time to wait for a lock to be acquired - default 2s]"
    bypass="[optional - if true will bypass the attempt to lock completely]"
{
.... do locked stuff here ...
}

Using our hotel reservation example, we can now perform a distributed lock like so:

var customer = customerService.get( customerId );
var hotelRoom = hotelService.getRoom( roomNumber );
redisLock
    name="reservationSystem_ReserveRoom_#roomNumber#"
    cache="redis-data"
    throwOnTimeout=false
    bypass=isDevelopmentMode() || isTestMode()
  {
     reservationService.reserve( hotelRoom customer );
	 return "Room number #roomNumber# has been successfully reserved!";
  }
  return "Room number #roomNumber# has already been reserved. Please select another room";

In this example, we set the throwOnTimeout value to false. If we fail to achieve a lock, it means the same room was being reserved and the code inside the body of the lock is not executed. As such, we return that the room was not able to be reserved. Note the use of the bypass argument to the lock. This can be handy for development or in testing when you are not using a distributed cache ( though you will need to have the extension installed to recognize what redisLock is! ) and simply want to execute the block.

Ortus Redis Extension v3.3.0 gives you greater control over concurrent modifications in a distributed environment, utilizing your distributed cache to prevent overlaps!

Read the full documentation here: Ortus Redis Cache Extension Documentation

 

Purchase Extension


Resources

Please visit our Extension page for all the necessary resources.

Add Your Comment

Recent Entries

Ortus March Newsletter

Ortus March Newsletter

Welcome to Ortus Solutions’ monthly roundup, where we're thrilled to showcase cutting-edge advancements, product updates, and exciting events! Join us as we delve into the latest innovations shaping the future of technology.

Maria Jose Herrera
Maria Jose Herrera
April 01, 2024
Into the Box 2024 Last Early Bird Days!

Into the Box 2024 Last Early Bird Days!

Time is ticking, with less than 60 days remaining until the excitement of Into the Box 2024 unfolds! Don't let this golden opportunity slip away; our exclusive Early Bird Pricing is here for a limited time only, available until March 31st. Why wait? Secure your seat now and take advantage of this steal!

Maria Jose Herrera
Maria Jose Herrera
March 20, 2024
Ortus February Newsletter 2024

Ortus February Newsletter 2024

Welcome to Ortus Solutions’ monthly roundup, where we're thrilled to showcase cutting-edge advancements, product updates, and exciting events! Join us as we delve into the latest innovations shaping the future of technology.

Maria Jose Herrera
Maria Jose Herrera
March 06, 2024