Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 3 of 3 total |
Pessimistiv & Optimistic Locking.. |
Tue, Dec 11 2018 2:01 AM | Permanent Link |
Ian Branch | Hi Team,
In a purely Local (Non Server) environment, and not using any Transactions per se, do the Pessimistic/Optimistic Locking settings for a session have any affect? Regards, Ian |
Tue, Dec 11 2018 3:07 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Ian
> In a purely Local (Non Server) environment, and not using any Transactions per se, do the Pessimistic/Optimistic >Locking settings for a session have any affect? If multi user - YES, if single user yes but who cares. The purpose of the pessimistic approach is that a record is locked when a user starts to edit it, if optimistic no such locking takes place. From the manual Editing an Existing Row The Edit method allows you to begin the process of editing an existing row in the dataset. ElevateDB offers the choice of a pessimistic or optimistic locking protocol, which is configurable via the RecordLockProtocol property for the TEDBSession assigned to the current dataset (see the SessionName property for more information on setting the session for a dataset). With the pessimistic locking protocol a row lock is obtained when the Edit method is called. As long as the row is being edited ElevateDB will hold a row lock on that row, and will not release this lock until either the Post or Cancel methods is called. With the optimistic locking protocol a row lock is not obtained until the Post method is called, and never obtained if the Cancel method is called. This means that another user or session is capable of editing the row and posting the changes to the row before the Post method is called, thus potentially causing an EEDBError exception to be raised with the error code 1007 (EDB_ERROR_ROWDELETED), or even error code 1008 (EDB_ERROR_ROWMODIFIED) if row change detection is turned on for the current session via the TEDBSession RecordChangeDetection property. In such cases you must discard the edited row by calling the Cancel method and begin again with a fresh copy of the row using the Edit method. and RecordChangeDetection This property was added to allow the developer to specify whether changes to a row will issue a warning exception when the row is updated or deleted. In DBISAM this behavior was not configurable and any changes to a row would cause an #8708 (DBISAM_KEYORRECDELETED) exception to be raised. TL:DR Last post wins is a possibility Roy Lambert |
Tue, Dec 11 2018 3:28 AM | Permanent Link |
Ian Branch | Thanks Roy,
Thanks for the clarification/confirmation, just wasn't certain. I have had Pessimistic locking set since the start. Regards, Ian |
This web page was last updated on Monday, May 6, 2024 at 03:23 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |