我是JPA的新手,请原谅我,如果不清楚的话。
基本上我想通过使用乐观锁定来防止并发修改。 我已将@Version属性添加到我的实体类中。
我需要知道处理OptimisticLockException的算法是否合理。 我将像Execute Around Idiom那样使用:
interface UpdateUnitOfWork
{
doUpdate( User user ); /* may throw javax.persistence.PersistenceException */
}
public boolean exec( EntityManager em, String userid, UpdateUnitOfWork work)
{
User u = em.find( User, userid );
if( u == null )
return;
try
{
work.doUpdate( u );
return true;
}
catch( OptimisticLockException ole )
{
return false;
}
}
public static void main(..) throws Exception
{
EntityManagerFactory emf = ...;
EntityManager em = null;
try
{
em = emf.createEntityManager();
UpdateUnitOfWork uow = new UpdateUnitOfWork() {
public doUpdate( User user )
{
user.setAge( 34 );
}
};
boolean success = exec( em, "petit", uow );
if( success )
return;
// retry 2nd time
success = exec( em, "petit", uow );
if( success )
return;
// retry 3rd time
success = exec( em, "petit", uow );
if( success )
return;
}
finally
{
em.close();
}
}
我的问题是你如何决定何时停止重试?
答案 0 :(得分:10)
我的问题是你如何决定何时停止重试?
在我看来,当在同一时间修改同一个对象是一种特殊情况时,应该使用乐观锁定。
现在,如果出现这种情况,并且该过程是手动的,我会警告用户无法保存修改并要求他再次保存更改。
如果进程是自动化的,那么实现自动重试机制是有意义的,但我不会重试3次或5次以上,具体取决于处理时间(我会使用递归调用来实现这一点) )。如果自动进程在并发访问问题上连续失败5次,那么它很可能与另一个自动化进程竞争,并且它们要么不处理独立的数据块(这对于并行化是不利的),要么策略不是正确的那一个。在这两种情况下,重试更多不是正确的解决方案。