2020-04-01 13:45
@杜福忠 但是我是hibernate那一套系统迁移过来的 sql语句没变化.那一套hibernate的加了二级缓存的,我唯一发现的不同点就是这一个了.我试试能不能尽可能提升效率吧
2019-02-11 11:54
我感觉没这么麻烦吧.我只用了一个方法就处理好了.所有返回方法我都是用的这个,能够返回json串
protected void returnJson(Object pojo){
renderJson(JFinalJson.getJson().toJson(pojo));
}
2019-01-17 10:10
@JFinal 还有点问题.我返回数据基本都是用的 renderJson(JFinalJson.getJson().toJson(Object pojo)) 返回各种数据.现在有一个问题就是我有一个方法会有195个请求左右同时并发,造成了该方法并发的时候,其他请求会很久之后才能进入到对应方法中.我有一个最上级的拦截器,继承了 PrototypeInterceptor,返回数据和最上级拦截器是不是对并发性能有影响.代码影响了并发.
2018-12-13 16:57
原因第一是因为在程序中创建了静态线程变量,druid的回收机制没有处理也不会识别. 第二,检查线程中对数据操作是否开启了autocommit,和数据库不一致,这个操作没操作好代码对线程池配置是致命的.第三,最好多线程测试时,事务控制用tx拦截器,不要自己画蛇添足.
2018-12-12 09:36
@JFinal 可以把 getmodal 方法也改一下吗? 当前端有多余的属性的时候,会报错.能不能把前端能够映射到modal里面的key都映射到实体类中,其他对应不上的就直接舍弃.
2018-11-23 11:51
我不清楚数据量问题.但是静态线程变量虽然 threadLocal 确实是同步的,安全的.但是我发现我在调用线程过后,虽然调用了close 方法.但是druid的回收机制没起作用.仍然有残留没清理的超时连接存在于连接池.当时我的并发量不高.我也不能确定是否是其他原因.之后我把静态线程变量那个类取消了就没问题了.并发过高只能通过很精密的测试来进行定位问题,我也在关注这个帖子,希望你解决了能在这里说下.
