"lost update" solution for web app?
GaffJan 28 2009 — edited Jan 29 2009Hi:
I'm building a web app using a tool that looks like it wants to commit every transaction before a call comes back to the database. I'm looking for the best solution for the "lost update" problem. If I weren't for being forced to commit I could "select * from update where..." and lock the row but in this case it would be canceled if this tool commits after issuing the select. I've seen code where people are using OWA_OPT_LOCK.checksum to return a checksum with the data and then when the application passes in the row to write back to the DB, the stored procedure checks to make sure that the checksum is the same as the one it gave to the user when the select was done. If not, assume the row has been modified by someone else and make the user try again.
Since that checksum is (at least on the ROWID version) based on the entire row, I was wondering if I could just have an integer value for every table that gets incremented in a trigger with every update. I'd pass the current integer value back to the application with the result set and compare that number with the current value of that column when trying to update a row.
Because I'm just loking to know that anything in the row has been modified and not just some subset of the columns, it looks like a more efficient way to do this rather than compute a checksum (although I'd need a trigger and sequence on every row). I was wondering if anyone had done this or if anyone sees a problem with this proposed solution.
Thanks.