今天在项目中加入hibernate bean validation.结果遇到了一点问题.由于对hibernate validation不是很了解,一开始没有找对问题的根源.以为是hibernate version的问题.其实不是,是hibernate validation和hibernate transaction整合有一个默认的BeanValidationEventListener.
这个位于hibernate 下的org.hibernate.cfg.beanvalidation.BeanValidationEventListener。会监听所有对实体类进行transaction.commit时的onPreInsert, onPerUpdate, onPerDelete。 这样每次transaction commit就会触发hibernate validation.
这一切原本都没有问题,但是由于我们加入了activiti.在执行异常处理以后forward页面以后执行activiti的查询,再次触发hibernate transaction commit,这样validation就也触发了,结果就是再次抛出同样异常.
解决方案:
1. 在执行activiti查询前进行判断如果request里有异常的errorkey就不执行查询,页面立即返回.
2. 给会返回异常的constraint加入groups(hibernate 默认对default groups的constraint 执行validation)
3. 不执行forward,执行redirect.这样页面上的version就会被更新成新的.(最终采用方案,如果确实读取的是脏数据就还原成数据库里的最新数据是正确的选择)
这个位于hibernate 下的org.hibernate.cfg.beanvalidation.BeanValidationEventListener。会监听所有对实体类进行transaction.commit时的onPreInsert, onPerUpdate, onPerDelete。 这样每次transaction commit就会触发hibernate validation.
这一切原本都没有问题,但是由于我们加入了activiti.在执行异常处理以后forward页面以后执行activiti的查询,再次触发hibernate transaction commit,这样validation就也触发了,结果就是再次抛出同样异常.
解决方案:
1. 在执行activiti查询前进行判断如果request里有异常的errorkey就不执行查询,页面立即返回.
2. 给会返回异常的constraint加入groups(hibernate 默认对default groups的constraint 执行validation)
3. 不执行forward,执行redirect.这样页面上的version就会被更新成新的.(最终采用方案,如果确实读取的是脏数据就还原成数据库里的最新数据是正确的选择)