Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Intermittent errors when using optimistic locking are to be expected. You need to add code to handle the errors.</p> <p>Optimistically concurrent code says something like,</p> <blockquote> <p>"I'm pretty sure, optimistic even, that no one else is going to touch this row while I'm working with it. Because of this, I won't bother 'pessimistically' locking the row. That way I won't get in the way of other people who simply want to read the row. I'm not stupid, though, so I'll double check before I write my changes to make sure nobody else updated the row while I wasn't looking. If they did, I'll raise an error instead of writing my changes."</p> </blockquote> <p>The end result is basically the same as the pessimistic approach; updates are occurring in an orderly fashion. Except now the non-writers are experiencing better read performance. However, if lots of things are trying to edit the same rows at the same time, sooner or later they're going to step on each other. If it happens enough, this can be pretty bad for write performance, as the writers have to keep retrying until they are successful.</p> <p>You say,</p> <blockquote> <p>"But wait! SQL updates are atomic! How could two updates possibly 'step on each other'?"</p> </blockquote> <p>I'm so glad you asked. Feel free to take a moment to read <em><a href="https://stackoverflow.com/questions/8058749/what-happens-if-2-or-more-people-update-a-record-at-the-exact-same-time/8060626#8060626">What happens if 2 or more people update a record at the exact same time?</a></em></p> <hr/> <p>Great! You're back. We have a few more things to talk about.</p> <p><strong>When should you use pessimistic locking instead of optimistic concurrency?</strong> Well, the names say it all. Use optimistic concurrency when you are optimistic that concurrent updates usually won't happen. On the other hand, if you're pretty pessimistic that concurrent updates are going to happen all the time, use pessimistic locking so that the database server can be in charge of making sure everybody waits in line to take their turn.</p> <p><strong>What should my code do in the event of an optimistic concurrency violation?</strong> Basically, it simply needs to retry until it gets through. The easiest way to do this is just display a message to the user saying, </p> <blockquote> <p>"Sorry, this record has changed. Your changes could not be saved. Please reload the page and try again."</p> </blockquote> <p>That leaves the user responsible with figuring out how the conflict should be resolved. The downside is, he'll have to re-enter his changes.</p> <p>You could get fancy with code that automatically retries in a loop until it doesn't receive that error, or fancier still with code that examined the other changes that were saved and tries to intelligently merge the changes together. If you actually have to start writing code like this, it might be a good indication that you would be better served with pessimistic locking.</p> <p><strong>Anything else, O Long-Winded One?</strong> Well, just remember that if Hibernate or NHibernate throws an exception, you need to throw the Session and associated entities away and get new ones. They now have an inconsistent picture of what the database looks like. You may have rolled back the database transaction, but the state of those in-memory objects was not rolled back. If this is a web app, and you're doing Session-per-request, <em>and</em> you take the "Tell the user 'Sorry'" approach, then this will be handled naturally by the user clicking the "Save" button again.</p>
    singulars
    1. This table or related slice is empty.
    1. POget HibernateOptimisticLockingFailureException while saving an object using merge
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USDaniel Schilling
    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
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