Originally posted by Thomas Bigbee:
... an update counter or a timestamp and some business logic during the save. Today most applications use a form of Optimistic Locking (we both work on the same record "at the same time", I save first, you try to save and are prevented or are allowed to merge "based upon configruation"), ...
Originally posted by: john prieur
These techniques seem to be addressing concerns that might be beyond the scope of the project requirements. Are transaction processing activities required? (not.) Record-level locking should be achieved as described. A race condition can be avoided by writing to the filesystem within the lifetime of a "lock". (I don't know why we would ever not want to use NIO for this.) If there is no explicit requirement that display-only data in the GUI is still valid, there is no implicit transaction. Data for update should, obviously, not change by others while user makes an update.
Hmm, I am going to start by answering the opposite to your question: "Do you think that cached approach is somehow worse than non-cached one?":
Do you think that non-cache approach is somehow worse than cached one?