2017-07-27 16:16
不是所有的应用场景都需要开启事务，我个人习惯于 Db.tx(...) 来做事务，看一下 FavoriteService.save() 这类方法中的 Db.tx 作法
要知道使用事务的目的是什么，是为了保持数据的一致性，有些情况下不需要开启事务也能保持一致性，就没有必要开启事务
2017-07-27 13:48
@linuxea 这么来添加拦截器，立即就能调试出来：
@Before({Tx.class, Tx.class})
也就是说，连续添加两个 Tx 拦截器
2017-07-27 12:46
@linuxea RedisInterceptor 会将 redis 连接放在 ThreadLocal 之中，那么当前线程如果多次使用 redis 的话，用的是同一个连接，不用再多次获取连接。 具体细节你得仔细调试Cache 类中的 getJedis() 与 close(Jedis jedis) 这两个方法，注意 ThreadLocal 的行为
2017-07-27 11:17
单步调试，观察一下 Cache.close(Jedis) 这个方法之中的细节看一下那个 if 语句是否为真，程序是否真的 close() 掉了这个连接，一切都清楚了
2017-07-27 11:15
刚刚注意到你的的程序是在 Job 中来使用 redis ，那么你的这个 Job 始终是在一个线程之中，注意看一下 com.jfinal.plugin.redis.Cache.java 源码中的 close(Jedis jedis) 方法，这个方法如果从 ThreadLocal 中获取不到连接时才去真的关闭连接，以此来实现 redis 的事务功能
所以，如果你使用的是 RedisInterceptor 或者调用 Redis.call(...) 方法，那么 Cache 的 ThreadLocal 中会有值，而 Job 是一直运行着的线程，所以会造成连接无法被关闭，多加两行代码，在 finally 块中关闭一下连接，例如：
try {
cache.get(...);
} finally {
cache.removeThreadLocalJedis();
}
注意前面有几个关键点：
1：你的程序直接或者间接的向 Cache 的 ThreadLocal 属性中放入了连接
2：使用 cache 的代码一直在一个线程之中不结束，例如 job 这样的
2017-07-27 10:58
这样用着就挺好，Redis.use() 方法并不会动用连接，只有实际去操作 redis 的时候才需要从连接池拿连接，而 redis.get(...) redis.set(...) 这所有的方法都在 finally 块中关闭过连接的，不会造成连接泄漏的情况
你的程序连接撑爆了，注意下面几点：
1：redis 服务端允许的最大连接数是否达到，例如，很多客户端同时连，而这些客户端初始化连接池时会首先创建很多连接到池里面
2：客户端配置的最大连接数是不是过小，造成并发稍多时就耗尽
3：自己的程序中是否自行通过 getJedis() 获取过连接，但是却没有在 finally 块中关闭连接，造成连接资源泄漏
2017-07-27 10:50
@Terry丶 俱乐部是增值服务，是为了积累一定的资源用于社区的基础开销与费用。没加入俱乐部的也几乎可以得到所有社区资源，例如文档、源代码等等
2017-07-26 15:46
maven 现在是标配，需要花一点点时间去学习，常用的命令就四五个而已
如果还不熟悉 maven，可以在首页下载一个 jfinal-all-3.1.zip 的文件，里头有一个所有 jar 包使用说明，以及所有需要的 jar 包，根据那个文档去使用却可
强烈建议要学会 maven 使用，然后在 pom.xml 中添加点东西就可以搞定 jar 包的问题
2017-07-26 14:48
@宅小达 注意一下是不是用的 jfinal weixin 1.9 版本，最新的文档是针对 1.9 版本的
