Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Great work attempting to be safe in write locking your changing data. :) But you might be going overboard / doing it the long way. </p> <ul> <li><p>First a minor point. The call to persist() isn't needed. For update, just modify the attributes of the entity returned from find(). The entityManager automatically knows about the changes and writes them to the db during commit. Persist is only needed when you create a new object &amp; write it to the db for the first time (or add a new child object to a parent relation and which to cascade the persist via cascade=PERSIST).</p></li> <li><p>Most applications have a low probability of 'clashing' concurrent updates to the same data by different threads which have their own separate transactions and separate persistent contexts. If this is true for you and you would like to maximise scalability, then use an optimistic write lock, rather than a pessimistic read or write lock. This is the case for the vast majority of web applications. It gives exactly the same data integrity, much better performance/scalability, but you must (infrequently) handle an OptimisticLockException.</p></li> <li><p>optimistic write locking is built-in automatically by simply having a short/integer/long/TimeStamp attribute in the db and entity and annotating it in the entity with @Version, you do not need to call entityManager.lock() in that case</p></li> </ul> <p>If you were satisfied with the above, and you added a @Version attribute to your entity, your code would be:</p> <pre><code>try { entityManager.getTransaction().begin(); r = entityManager.find(Route.class, r.getPrimaryKey()); r.setRoute(txtRoute.getText()); entityManager.getTransaction().commit(); } catch (OptimisticLockException e) { // Logging and (maybe) some error handling here. // In your case you are lucky - you could simply rerun the whole method. // Although often automatic recovery is difficult and possibly dangerous/undesirable // in which case we need to report the error back to the user for manual recovery } </code></pre> <p>i.e. no explicit locking at all - the entity manager handles it automagically.</p> <p>IF you had a strong need to avoid concurrent data update "clashes", and are happy to have your code with limited scalability then serialise data access via pessimistic write locking:</p> <pre><code>try { entityManager.getTransaction().begin(); r = entityManager.find(Route.class, r.getPrimaryKey(), LockModeType.PESSIMISTIC_WRITE); r.setRoute(txtRoute.getText()); entityManager.getTransaction().commit(); } catch (PessimisticLockException e) { // log &amp; rethrow } </code></pre> <p>In both cases, a successful commit or an exception with automatic rollback means that any locking carried out is automatically cleared.</p> <p>Cheers.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload