2018-11-02 15:14
@年轻人 因为 TRANSACTION_REPEATABLE_READ 级别的事务并发性能比 TRANSACTION_READ_COMMITTED 要差
事务越是严格，并发度越低，例如最后一个 TRANSACTION_SERIALIZABLE 这个级别是的串行处理请求，也就是请求过来以后，一个一个通过，不允许并发，这个性能就会低到无法忍受
2018-11-02 11:34
很多基于 jfinal 自动扫描路由的扩展可用
建议先试用两天 jfinal 默认的方式，少了注解代码其实更干净
2018-11-01 20:59
要先调用 getFile、getFiles 系列方法，然后才可以调用 getPara、getModel 这类方法，文档中有过说明
注意，如果有拦截器、Validator 也要先在其中调用 getFile、getFiles 系列的方法
2018-11-01 19:45
@JM-java 已经在文档中添加了：http://www.jfinal.com/doc/5-7
感谢你的反馈，后面有同学碰到这个问题就能节省大量时间了
2018-11-01 17:15
@tuxming jfinal 的数据库操作部分仅仅是对 JDBC 进行了一个极薄封装，在本质上就是将你的 sql + para 直接扔给了底层的 JDBC，想要出错都是很困难的，因为 JDBC 是很稳固的
2018-11-01 17:13
@JM-java JDBC 默认的 Connection.TRANSACTION_READ_COMMITTED 适用于多数情况，jfinal 调高一级是为了避免某些用户的业务本身对事务级别本身要求就高，然后出错以后怪罪 jfinal，但这种事本质上是与 jfinal 无关的
2018-11-01 17:02
@zzh1234567 除了这个办法以外，还可能过继承 MetaBuilder 并覆盖其中的 isSkipTable 方法，通过判断 tableName 前缀或者通过正则表达式，跳过一些不需要处理的类
2018-11-01 15:31
@zzh1234567 数据库完全不动， 仅将你项目中的 oracle 的那个驱动 jar 包升级，这个与数据库升级完全无关
2018-11-01 11:14
缺少 freemarker 的 jar 包而已，注意看 NoClassDefFoundError
此外，建议升级到 jfinal 3.5，3.4 升到 3.5 没有什么考虑的，全是好处
2018-11-01 11:13
因为每次请求过来，都是使用新创建的 controller 对象处理请求的，该 controller 对象是线程独享的，所以线程安全
具体代码在 ActionHandler 中有一个 controllerFactory.getController(...);
2018-11-01 11:09
未调用 remove() 方法移除对象，那么该对象会一直被 Thread 持有，该 Thread 下次接收到任务时可以再次获取到前面创建的对象，从而实现了类似对象缓冲池的效果
jfinal 官方这周会将 tomcat\jetty 换成 undertow，不会再出现这样的提示
