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.

• Purchase
• Capabilities
• Trial Version