I suppose this could be done. However, we couldn't just change the defualt for the flag or something. We would also have to enhance the form widget and the service engine to automatically pass around the extra field in order to avoid having to manually add it to every form and service in the system. Of course, any forms in FTL or other non-form-widget tools would still need to have the timestamp field manually added.
The performance wouldn't be too bad. It is already pretty common practice throughout the system to query the latest record before updating it. -David On Jan 7, 2010, at 5:48 AM, Christopher Snow wrote: > Hi David, > > Just out of interest, why is the enable-lock="true" not the default setting? > Is it for performance reasons? > > Many thanks, > > Chris > > David E Jones wrote: >> This is usually referred to as an "optimistic lock", and yes this can be >> turned on per-entity in the entity definition itself. In some cases logic >> and UI changes will be necessary to support this, ie in order to support >> passing the timestamp that represents the "version" of the record to make >> sure it is the same when saving the changes. >> >> -David >> >> >> On Jan 6, 2010, at 9:56 AM, Christopher Snow wrote: >> >> >>> I have just done a quick test and it appears that if two users are editing >>> and save the same record, the last save wins. Is it possible to change >>> this behavior to throw an error if the data is stale, like hibernate's >>> StaleObjectStateException? >>> >>> Many thanks, >>> >>> Chris >>>
