从JPA文档中,如果没有人持有实体上的PESSIMISTIC_READ锁,则可以获得该实体的PESSIMISTIC_WRITE锁。但是,当我使用OpenJPA 2.0.0、WebSphere和MSSQL (以及DB2)进行测试时,两个服务似乎不能同时获得同一个实体上的PESSIMISTIC_READ锁。
此代码(在ConfigEJB中)用于锁定实体:
ConfigEntity configEntity = this.getEntityById(1); // successfully get the entity
this.entityManager.lock(configEntity, LockModeType.PESSIMISTIC_READ);调用了2个ConfigEJB实例。第一个实例可以成功地获取锁。但是,第二个实例无法获得锁,直到第一个实例完成它的事务(我期望它成功地获得锁)时才被阻塞。
有人遇到过这个问题吗?或者这是JPA的预期行为?如何让服务正确地获得PESSIMISTIC_READ锁?
发布于 2014-03-25 05:17:43
在参考文献中没有找到,但是Pro JPA2说:
一些数据库支持锁定机制以获得可重复的读隔离,而无需获取写锁。当不需要对实体进行写入时,可以使用PESSIMISTIC_READ模式悲观地实现可重复的读取语义。这种情况不会经常发生,再加上提供者使用悲观写锁实现这种情况的允许性,这一事实使我们不得不说,这种模式不是一种容易掌握和普遍使用的模式。
因此,您的数据库提供程序似乎将PESSIMISTIC_READ替换为PESSIMISTIC_WRITE。
https://stackoverflow.com/questions/22625804
复制相似问题