2019-08-16 12:03
先尝试这两个 sql 内容一起拥到 Db.update(...) 中去，因为你这个 sql 是有分号结尾的，或许一次性可以执行多条
如果不成功，则按分号解析出一条条的 sql 去执行，这些显然都与 jfinal 无关了
2019-08-16 12:01
@周中中 用了以后不用 stop()， 只有在你确定某个数据源不使用的时候才去 stop()
可以通过 DbKit.getConfigSet() 获取所有 Config 对象，Config 对象中持有数据源，可以通过 Config.getDataSource() 进一步获取
2019-08-16 10:22
你的用法是对的， sql 从文件中读出来使用普通的 java API 即可
假定你的 sql 是按行存放的，可以通过 BufferedReader 按行读取，
String sql = reader.readLine();
然后 Db.update(sql);
2019-08-16 10:18
@肖兔兔 用多少个都可以，注意要使用 cos 2019.8 这个版本才支持多文件上传时 input 的 name 值相同
否则 input 的 name 值需要不同才支持
2019-08-16 08:26
与性能有关的因素极多，数据源仅仅是其中一个而已
如果你的第个数据源都很快，性能影响可以忽略不计，我就见过有人使用 jfinal 开发的项目用到了上千个数据源
数据源个数无上限
数据源可以动态配置，你只需要手动 new DruidPlugin()， 再手动 new ActiveRecord(...)， 再手动 start() 启动这两个组件， 不用的时候 stop() 这两个组件即可，参考这一章的内容：
https://www.jfinal.com/doc/5-15
2019-08-16 08:23
@liugz 在不支持 cookie 的场景下，参过在 url 中问号挂参，或者表单传参的方式传给服务端
2019-08-15 20:40
@373118970 用上 jfinal 提供的 jfinal-undertow 来开发、运行、部署，是一体化的方案，不必折腾各种配置：
https://www.jfinal.com/doc/1-2
2019-08-15 20:39
@JPEGIF jfinal 只负责生成，是不是永久得看你如何定义这个永久
你可以认为在 jfinal 的世界，只要你生成二维码使用的参数不变，那它就是永久的
2019-08-15 20:36
jfinal 与 spring cloud 是不同的领域，前者是 web + orm + aop + template engine 框架，后者是微服务技术栈，无法相比较
jfinal 要比较的话，是要同 spring boot 比较，其中的 web 部分属于同类，但 spring boot 的 orm 与 template engine 等模块都是集成的第三方，jfinal 这些功能都是自己手写，确保极简与高品质
关注一个技术是不是很老，还不如关注一个技术是不是最好用，如果一个很古老的技术直到现在都很好用，恰恰验证了其优秀
你可以试用一下 spring cloud ， 买本书看一看，应用成本非常之高，对于绝大多数项目用用集群就搞定了，根本用不上 spring cloud
spring cloud 是对很多种技术的一个整合性的技术栈，是个大杂汇，我从来没见过哪家公司真正能将之用起来的，这个技术栈涉及面非常广：
服务治理整合的 Eureka
客户端负载均衡整合的 Ribbon
服务容错保护整合的 Hystrix
声明式服务调用整合的 Feign
Api 网关整合的 Zuul
消息总线整合的 RabbitMQ 或 Kafka
分布式服务跟踪整合的 Sleuth
web 框架整合的 spring boot
其它功能的整合不再赘述，总之用到啥就得去整合
spring 那套东西与 jfinal 基本是相反的路，jfinal 做小而精，核心功能都是自己写，保持极简设计，学习成本低，spring cloud 与 spring boot 绝大部分功能都是去整合，走的大而全的路
上面谈到的这些技术， 你要用上 spring cloud 的步骤大致如下：
1：将你的项目先拆分成小型的项目，也就是所谓的微服务。根据项目大小去拆分，有些人一个项目能拆成十多个微服务
2：拆分之前各模块的调用是方法调用，拆分后变成了服务间调用，一般是走 http、rpc 等机制，不仅徒增很多开发成本，而且会拉低性能，服务间通信的效率比方法调用要低得多
3：将前面谈到的一些技术用到的软件安装、配置、部署起来
4：按照 spring cloud 各项技术的要求，将第一步拆分的项目分别部署起来
这么多的技术全部跑起来并且进行维护的成本是极高的，99.9% 的公司顶多弄弄集群就搞定的事，根本不需这么来弄
剩下来有需要的是有钱、有人的大公司，而大部分大公司都有自己的一套分布式解决方案，仍然也用不上这些东东，这就是 spring cloud 的尴尬之处
最后，由于 spring cloud 的应用成本如此之高，未来分布式的趋势是走 k8s + docker + rancher 的技术路线，不仅成本低，而且对于应用来说是透明的，也就是说你开发的项目根本不用管分布式的事情，全交给更底层的容器来解决
jfinal 早在去年就思考过要不要介入微服务，也正由于 k8s + docker + rancher 这类技术路子更适合未来分布式的方向，所以 jfinal 才没出手微服务的事
一定要记住：选择不做什么比做什么更重要
2019-08-15 14:58
@戒不掉 线程之间是独立的，不会有影响，我怀疑是你的 afterJFinalStart() 因为大小写问题或者字母错误没有被回调
新版本 jfinal 支持 onStart() 回调，方法名改成 onStart() 再断点调试一下，这里有相关文档：
https://www.jfinal.com/doc/2-8
2019-08-15 09:24
@373118970 异常中出现了 spring 字眼，我估计应该是 spring 的问题， 当成是 spring 的问题搜索一下解决办法
