SCJP
SCJP
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"), ...
Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
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.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP, SCJD
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?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP, SCJD