2019-01-11 10:54
这个是 tomcat 误报而已,严格来说也不是误报,因为 tomcat 的措辞是:"probable memory leak"。也就是说 tomcat 也只是猜测可能有内存泄露
为了重用 buffer,避免内存分配, jfinal enjoy 引擎使用 ThreadLocal 绑定了 buffer。这个 buffer 的生命周期与 Thread 是一样长的,所以被 tomcat 误报
关于这个问题 jfinal 官方是经过严格测试的,例如进行了最为极端的测试:每次请求 new 出新线程来绑定 buffer,观测 buffer 是否被回收,确证回收无误。
而 jfinal enjoy 的 buffer 在实际使用时是与线程池中的 Thread 绑定的, new 出来的 buffer 的数量是确定的。
你使用 jfinal undertow 就不会误报这个信息了,建议切到 jfinal undertow。如果你是在使用 Spring ,也可以用它的 undertow
2019-01-10 16:17
@zzzzcat 直接传入 page 对象就可以了:
setAttr("page", page);
模板中这么用:
#for (x : page.getList())
...
#end
enjoy 的表达式与 java 是直接打通的,所以你可以调用 page.getList() 获取 List 对象,并对其进行迭代
2019-01-10 16:16
@彼岸的包子 刚看了一下,确实是这样,目前建议你按如下办法解决:
1:创建 public class MyDbPro extends DbPro,覆盖掉其中的 batchSave(...) 方法,仿照 batchUpdate(...) 方法添加过滤
2:创建一个 MyDbProFactory:
public class MyDbProFactory implements IDbProFactory {
public DbPro getDbPro(String configName) {
return new MyDbPro(configName);
}
}
3:在 configPlugin 中配置一下 ActiveRecordPlugin 对象:
arp.setDbProFactory(new MyDbProFactory());
这样就可以将自己改进过的 MyDbProFactory 切换过去了,记得搞定后回来分享一下,这个是有价值的改进
2019-01-10 15:32
@1174133584 本质上来说:
1:分页需要得到 totalRow、totalPage,也就是当前你这个 sql 分页时要得到总记录数与总页数,那么 jfinal 需要生成一条 sql 来获取
2:生成的这条 sql 就需要将你的 select 部分给替换成 select count (*) 语句,这样就会丢失掉你在 select 中带的一些参数
3:jfinal 以前的版本曾经试图用正则替换来精准解决这个问题,但性能差了两个数量级,权衡下,提供了 paginateByFullSql 以及文档说明来辅助大家来解决
2019-01-10 15:29
@lyf78062919 这个认知十分深入,从来没有人这么有耐心的研究过这个问题,贴子已收藏,下次有同学需要直接给贴子链接,谢谢