Spring-session: Why is Lettuce the default Redis client used in Spring Session Redis?

Created on 24 May 2017  路  2Comments  路  Source: spring-projects/spring-session

Why Lettuce over Jedis? Is this an arbitrary decision or is there a technical reason behind this decision?

Thank you.

Most helpful comment

Thanks for asking. This decision is backed by technical reasons.

_I might be biased as I'm the maintainer of Lettuce. Please find the explanation below._

Both libraries are great Redis drivers, Jedis is the de-facto standard driver for Java-based applications.

We used both drivers in production and saw an improved resource usage scheme with Lettuce regarding connection use.

Jedis is a straight-forward Redis client that is not thread-safe when applications want to share a single Jedis instance across multiple threads. The approach to use Jedis in a multi-threaded environment is to use connection pooling. Each concurrent thread using Jedis gets its own Jedis instance for the duration of Jedis interaction. Connection pooling comes at the cost of a physical connection per Jedis instance which increases the number of Redis connections.

Lettuce is built on netty and connection instances (StatefulRedisConnection) can be shared across multiple threads. So a multi-threaded application can use a single connection
regardless the number of concurrent threads that interact with Lettuce.

Limiting the number of connections can be required when using connection limits on Redis or when the number of connections grows beyond a reasonable connection count.

Does this make sense?

All 2 comments

Thanks for asking. This decision is backed by technical reasons.

_I might be biased as I'm the maintainer of Lettuce. Please find the explanation below._

Both libraries are great Redis drivers, Jedis is the de-facto standard driver for Java-based applications.

We used both drivers in production and saw an improved resource usage scheme with Lettuce regarding connection use.

Jedis is a straight-forward Redis client that is not thread-safe when applications want to share a single Jedis instance across multiple threads. The approach to use Jedis in a multi-threaded environment is to use connection pooling. Each concurrent thread using Jedis gets its own Jedis instance for the duration of Jedis interaction. Connection pooling comes at the cost of a physical connection per Jedis instance which increases the number of Redis connections.

Lettuce is built on netty and connection instances (StatefulRedisConnection) can be shared across multiple threads. So a multi-threaded application can use a single connection
regardless the number of concurrent threads that interact with Lettuce.

Limiting the number of connections can be required when using connection limits on Redis or when the number of connections grows beyond a reasonable connection count.

Does this make sense?

Thanks for the detailed response. I'm closing this. If you need more information please reopen.

Was this page helpful?
0 / 5 - 0 ratings