2016-09-12 16:43
@老八 如果要用到集群，可以参考一下这个贴子后面的回复。即便不用集群创建 task与调度 task 分开的事情也是很有好处的。可以点击贴子下方的五角星收藏贴子，方便以后开发的时候有问题再回头查看
2016-09-12 16:33
@九爷同学 其实与其去学习 quartz 的分布式用法，还不如自己建一个 task 表来得简单，而且 task 本身就是需要的，可以记录任务调试的情况，心中有数
2016-09-12 16:33
@九爷同学 cron4j 不支持集群，需要自己写点代码处理好集群部署时的协作。给个方案：
1：将 task 创建与 task 调度分开
2：创建 task 时，向一个集中的数据库表写入记录，假定就叫 task 表
3：task 表中放一个 int lock 字段，用来在分布式环境下来上锁
4：集群中的 taks 调度程序在事务中为将要处理的 task 记录的 lock 字段上锁，置为 1，然后开始处理，其它调度程序在调度的时候发现 lock 为 1 时不处理
这里再建议两个小设计：
1：创建一个 status 字段表明处理状态，根据需求值可以是：0初始、1正处理、2成功、3失败
3：基于 Cron4j 的调度程序在最开始一段代码前面，加一句 Thread.sleep(随机数毫秒数); 这个随机的毫秒数可用 new Random().nextInt(2000); 这样的代码来生成。这样做的好处是避免集群环境下多个使用同样 cron 表达式的线程过于竞争
2016-09-12 15:58
建议先用用 jfinal 官方将要出品的 Cron4jPlugin，在此下载： http://www.jfinal.com/share/37
2016-09-12 12:34
除了 cron4j 配置可能有错误以外，还要检查一下是不是 tomcat 配置的坑，请看这里：http://my.oschina.net/jfinal/blog/353062
2016-09-11 18:03
而对于 Model，由于 Model 事先与 table 建立了映射关系，所以在 findById(...)、findByIdLoadColumns(...) 这类查询时，tableName 与 idName 这两个参数是天然不需要的，所以此时的重载比较简洁易用
2016-09-11 18:01
如果添加 Db.findByIdLoadColumns(...) 这个特性，由于参数非常多，还不如直接用 Db.findFirst("select a,b,c from ...", p1, ...pn) 来得方便快捷，而且不需要去学习那些参数的含义，降低了学习成本
2016-09-11 17:59
无论是 Model 还是 Db，早在 jfinal 1.9 的时候， findById 都有重载实现 loadColumns 的功能，那时方法名全叫 findById(...)，用重载实现的
到了 jfinal 2.0 添加了多主键支持，Model、Db 中的 findById 必须跟着变化，而 findById 本来重载的方法就很多了，所以添加多主键支持时，重载方案下的参数的各种组合变得很复杂，也容易让用户用错
所以 jfinal 2.0 的 Model 将该功能改了方法名，由 findById 改为了 findByIdLoadColumns，避免了重载带来的各种问题
而 jfinal 2.0 多主键支持下的 Db 类情况更加麻烦，由于 Db + Record 模式下的各种查询方法需要传入 tableName，甚至 idName，所以参数数量更加多，在使用过程中，如果将这些参数都用上，发现还不如直接在 sql 的 select 中带上这些个 columns 来得方便，并且易于理解，所以 2.0 就干脆将 Db 上的这个特性干掉了
重载是面象对象语言的很优秀的特性，但在参数过多时也会带来一些问题
2016-09-11 12:53
@小木学堂 昨晚服务器迁移，停服了几个小时，mysql 5.7 有坑啊，居然不兼容某些 mysql 5.6 的 sql
