Jedis returnBrokenResource returnResource的标准写法

最新推荐文章于 2023-09-22 09:02:55 发布

pengpengzhou

最新推荐文章于 2023-09-22 09:02:55 发布

阅读量5.6k

点赞数

本文探讨了Jedis客户端3.0版本及之前的连接管理方式。重点介绍了Jedis3.0之后如何处理连接异常，并返回连接到池中；而3.0之前版本则需要通过特定的方法标记损坏的资源并将其归还给连接池。此外，还讨论了不同类型的异常及其处理策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Jedis 3.0 以后（含3.0）

finally {
  if (jedis != null) {
    jedis.close();
  }
}

If Jedis was borrowed from pool, it will be returned to pool with proper method since it already determines there was JedisConnectionException occurred. If Jedis wasn't borrowed from pool, it will be disconnected and closed.

Jedis 3.0 以前

public String get(String keyName)
{
    Jedis redis = null;
    try
    {
        redis = redisPool.getResource();
        return redis.get(keyName);
    }
    catch (JedisConnectionException e) 
    {
        if (redis != null) 
        {
            redisPool.returnBrokenResource(redis);
            redis = null;
        }
        throw e;
    }
    finally
    {
        if (redis != null)
        {
            redisPool.returnResource(redis);
        }
    }
}

You are supposed to use returnBrokenResource when the state of the object is unrecoverable. A Jedis object represents a connection to Redis. It becomes unusable when the physical connection is broken, or when the synchronization between the client and server is lost.
With Jedis, these errors are represented by the JedisConnectionException. So I would use returnBrokenResource for this exception, and not the other ones.
JedisDataException is more related to bad usage of the Jedis API, or to server-side Redis errors.
JedisException is for everything else (usually raised after a lower-level error, independant from Jedis).