Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Artem,</p> <p>Can you briefly explain what is it you're trying to achieve? Bird's eye view, obviously - like is this (invoked from) UI code? Or is it server-side process (so you'd have direct controls over threads)? The reason I ask is I get a (perhaps incorrect) feeling from this and your other related questions that you're trying to use optimistic locking for something it wasn't designed for and that's what's causing all the trouble.</p> <p>As far as <code>StaleObjectStateException</code> goes, it is most definitely thrown from both <code>DefaultFlushEventListener</code> and <code>AutoFlushEventListener</code> that handle explicit / implicit flushes. Are you invoking flush() manually? If not, perhaps the exception is being caught / logged by wrapper code around auto flushing (Spring? TransactionManager? EntityManager?)</p> <p><strong>Update</strong></p> <p>Thank you for clarifying the question. I'm still a bit unclear about whether you want to prevent multiple <strong>threads</strong> from <i>concurrently modifying</i><sup>1</sup> the same entity or prevent multiple <strong>users</strong> from trying to concurrently edit it.</p> <p>Former scenario can be handled via optimistic locking; however without explicit <code>flush()</code> it becomes non-deterministic (thread that made the modification first may not be flushed / committed first). See my answer to <a href="https://stackoverflow.com/questions/1399679/can-hibernates-version-consider-changes-in-related-entities">this question</a> for more details. Another problem with automatic flush is what you're currently experiencing - failed version check is not discovered until flush and, if that flush coincides with attempt to commit transaction, exception thrown is RollbackException. Either way, entire transaction is rolled back. </p> <p>Latter scenario (preventing users from editing) can NOT be handled by optimistic locking. You will need to implement pessimistic locking instead - either at the database or application level. In other words, the process is:</p> <ol> <li>user wants to edit entity</li> <li>check if lock exists on entity</li> <li>YES - prohibit editing (allow read-only view?)</li> <li>NO - lock entity, allow editing</li> <li>commit (cancel) changes; release lock</li> </ol> <p>Be sure to expire existing locks after a certain period of user inactivity if you go with this approach.</p> <hr> <p><i>concurrently modifying</i><sup>1</sup> is not really accurate in this case (that's what transactions are for); we're talking about preventing one thread from overwriting edits of another based on older version.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to detect transaction conflicts with Hibernate?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USChssPly76
    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. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you. I have updated the question with the info you asked.
      singulars
      1. PO
      1. USartemb
    2. COI am trying to prevent multiple threads from concurrently modifying. Exactly preventing one thread from overwriting edits of another based on older version. So your advice is flushing manually? Only that way I can achieve my goal?
      singulars
      1. PO
      1. USartemb
    3. COConsider this: threads T1 and T2 read your entity at the same time, modify it, then T1 saves it and T2 saves it. With auto flush you don't know whose changes (T2 or T1) are going to be flushed first. Furthermore, until changes are flushed (and / or transactions committed depending on isolation) the other thread won't even know that object version has changed so you only get the error back when transaction fails and is being rolled back. If you care about change order or want to get exception early, you have to flush manually.
      singulars
      1. PO
      1. USChssPly76
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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