Applications that interactively display table information like web
clients and gui applications, normally would have to cache the data in
the table rows being displayed (e.g. have copies), that could be changed
if there was a lesser degree of information locking ;
is there an idiom that's commonly used to make sure that these
applications don't overwrite concurrent earlier commits that haven't
been seen by a client ?
I know of an app that does xmin checking, but I was thinking
that if before an update is issued, the original old value that
was cached was compared with a newly re-read old value at the start
of the update transaction, was found to be different, then the update
should fail , because that means an update had been issued elsewhere
that had been uncommunicated. Is that the usual idiom ?
This would mean every write would need to be preceded by a select
for the old value, and every old value which was originally
cached needs to be stored separate from the current client's version
of the value.
What other ways are there of doing such an app?