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 |
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 > > |
Thanks David.
I can see the attribute enable-lock on the entity. Do I just set this to true 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 >> >> >> > > -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk |
Whoops - accidental post.
I had seen the definition in http://ofbiz.apache.org/docs/entity.html and it explains everything! Christopher Snow wrote: > Thanks David. > > I can see the attribute enable-lock on the entity. Do I just set this > to true > > 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 >>> >>> >>> >> >> > > -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk |
In reply to this post by David E. Jones-2
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 >> >> >> > > -- Chris Snow - CEng MBCS CITP MBA (Tech Mgmt) (Open) CISSP Tel: 01453 890660 Mob: 07944 880950 Www: www.snowconsulting.co.uk |
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 >>> |
Free forum by Nabble | Edit this page |