2017-07-27 20:51

再回到你的问题,模板文件只有一个入口文件,也就是 render(...) 方法中的参数所指向的那个模板文件,而一个模板文件没有太多必要搞出方法重载这类功能。所以 jfinal 模板引擎并不支持函数同名

解决方法可以是利用 #render 指令,为其传入动态的模板参数,实现模板的组合,这些个模板中定义的函数可以是同名的, #render 指令所处理的模板文件中的
#define xxx() 函数名是可以重名的,她们拥有各自的作用域

2017-07-27 20:48

你给出的结构图其实并不贴切,jfinal club 用于实现 layout 功能的方法,在本质上就是简单的函数调用:
1:#define layout() 定义 layout() 函数
2:layout() 函数中分别调用了 main() js() css() 这三个函数
3:定义 layout() 函数的模板文件通过 addSharedFunction(...) 将其置为共享函数,你可以认为是在最终的页面用 #include("__layout.html") 包含进来了而已
4:最终页面先是调用了 layout() 函数,然后 layout() 会调用 main()、js()、css(),而这三个函数在最终页面通过 #define 定义出来即可

简单来说:
1:最终页面,例如 index.html 是程序入口
2:在程序入口调用了 layout()
3:layout() 调用了定义在本页面定义的 main() js() css()

由于函数/方法几乎是所有程序语言中都有的现成的概念,所以理解起来非常符合直觉

2017-07-27 16:57

@杜福忠 这个是正解

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 13:05

@linuxea 单步去调试比光去想要高效得多,而且不易出错

2017-07-27 12:47

@Joph_csu 注意在 finally 块中进行关闭,否在出现异常时仍然会造成连接资源泄漏

2017-07-27 12:46

@linuxea RedisInterceptor 会将 redis 连接放在 ThreadLocal 之中,那么当前线程如果多次使用 redis 的话,用的是同一个连接,不用再多次获取连接。 具体细节你得仔细调试Cache 类中的 getJedis() 与 close(Jedis jedis) 这两个方法,注意 ThreadLocal 的行为

2017-07-27 11:44

@淡定007 mls 是你 new 出来的一个 ArrayList ,怎么可能是 null 呢?

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:52

使用 Model.put(Record) 方法能将 Record 转成Model

2017-07-27 10:50

@Terry丶 俱乐部是增值服务,是为了积累一定的资源用于社区的基础开销与费用。没加入俱乐部的也几乎可以得到所有社区资源,例如文档、源代码等等

2017-07-26 18:37

只能单步调试去领悟