optimistic-locking

Transaction is not completely rolled back after server throws OptimisticLockException

由 有些话、适合烂在心里 提交于 2019-12-11 03:21:52
问题 Let's say I have an entity bean AccountBean with version field (javax.persistence.Version annotation). During transaction my application modifies this entity and performs database operations on other entities (inserts and updates rows). Some of those entity beans have @Version field but not all of them. When the same AccountBean entity is modified concurrently by 2 threads, OptimistickLockException is thrown and (at least according to server log) the transaction is rolled back. However, only

RavenDB UseOptimisticConcurrency in Config?

由 自闭症网瘾萝莉.ら 提交于 2019-12-11 02:53:03
问题 Is there a way to set optimistic concurrency to true in Raven.Server.exe.config? Or, can it somehow be applied at the database level? On RavenDB's site, I see a couple of mentions of setting UseOptimisticConcurrency = true, but it looks like it's at the session level within the code: public void Save<T>(T objectToSave) { using (IDocumentSession session = Database.OpenSession()) { session.Advanced.UseOptimisticConcurrency = true; // This is the setting Guid eTag = (Guid)session.Advanced

How to catch OptimisticLockException in JPA

由 本小妞迷上赌 提交于 2019-12-11 02:07:41
问题 I've read out a couple of questions here regarding the OptimisticLockException with JPA, used in an stateless session bean. It is thrown, but not where I expect it obviously. Here is the code where I expect to get the exception: try { productFacade.edit(product); } catch(Exception { return "lock"; } The productFacade is generated with NetBeans and it is an EJB with a local interface, an it implements an AbstractFacade abstract class. As far as I read, this has something to do with

EntityManager throws OptimisticLockException when try to delete locked entity in same transaction

由 丶灬走出姿态 提交于 2019-12-10 17:48:23
问题 Here is my code: EntityManager em = JPAUtil.createEntityManager(); try { EntityTransaction tx = em.getTransaction(); try { //do some stuff here tx.begin(); List es = em.createNamedQuery("getMyEntities", MyEntity.class).getResultList(); for (MyEntity e : es) { em.lock(e, LockModeType.OPTIMISTIC); } if (es.size() != 0) { em.remove(es.get(0)); } tx.commit } finally { if (tx.isActive()) { tx.rollback(); } } } finally { em.close(); } When I'm executing that code I get : ... .......... Caused by:

How to overcome StaleObjectStateException in grails Service

由 为君一笑 提交于 2019-12-10 11:22:28
问题 I've introduced a TransactionService that I use in my controllers to execute optimistic transactions. It should try to execute a given transaction (= closure) roll it back if it fails and try it again if it fails It basically looks like this: class TransactionService { transactional = false // Because withTransaction is used below anyway def executeOptimisticTransaction(Closure transaction) { def success = false while (!success) { anyDomainClass.withTransaction { status -> try { transaction()

JPA: OptimisticLockException and Cascading

由 試著忘記壹切 提交于 2019-12-09 06:45:30
问题 In my current project I use Spring Data JPA with Hibernate but consider this as a more general question that should also cover "plain" JPA. I'm uncertain how I should deal with OptimisticLockException when using @Version . Due to how my application works some relationships have CascadeType.PERSIST and CascadeType.REFRESH , others also have CascadeType.MERGE . Where to handle OptimisticLockException As far as I can tell handling this on the service layer won't work especially with CascadeType

Can I add a condition to CakePHP's update statement?

由 让人想犯罪 __ 提交于 2019-12-08 02:22:13
问题 Since there doesn't seem to be any support for optimistic locking in CakePHP, I'm taking a stab at building a behaviour that implements it. After a little research into behaviours, I think I could run a query in the beforeSave event to check that the version field hasn't changed. However, I'd rather implement the check by changing the update statement's WHERE clause from WHERE id = ? to WHERE id = ? and version = ? This way I don't have to worry about other requests changing the database

How to overcome StaleObjectStateException in grails Service

由 时间秒杀一切 提交于 2019-12-06 10:47:56
I've introduced a TransactionService that I use in my controllers to execute optimistic transactions. It should try to execute a given transaction (= closure) roll it back if it fails and try it again if it fails It basically looks like this: class TransactionService { transactional = false // Because withTransaction is used below anyway def executeOptimisticTransaction(Closure transaction) { def success = false while (!success) { anyDomainClass.withTransaction { status -> try { transaction() success = true } catch(Exception e) { status.setRollbackOnly() } } } } } It is a little more complex,

Can I add a condition to CakePHP's update statement?

由 夙愿已清 提交于 2019-12-06 08:16:10
Since there doesn't seem to be any support for optimistic locking in CakePHP , I'm taking a stab at building a behaviour that implements it. After a little research into behaviours, I think I could run a query in the beforeSave event to check that the version field hasn't changed. However, I'd rather implement the check by changing the update statement's WHERE clause from WHERE id = ? to WHERE id = ? and version = ? This way I don't have to worry about other requests changing the database record between the time I read the version and the time I execute the update. It also means I can do one

Optimistic locking in a RESTful application

由 纵饮孤独 提交于 2019-12-04 22:49:27
问题 At work, we're developing a RESTful application where the data layer will be handled by Hibernate. But we're not sure how to handle updates on entities. We're planning to do the following: 1) client requests an entity by id 2) Hibernate loads the entity, the requested fields (always with the version) are copied to a DTO that is converted to JSON and sent to the client 3) Client manages some fields and sends the entity (with version number) back to the server. 4) Server receives the JSON that
订阅 optimistic-locking