Question:
How can I set the flushing of rows to the database or the locking strategy used by Power Objects?
Answer:
Oracle Power Objects ‘supports’ two ways that rows can be flushed to the database – immediate and deferred. Immediate flushing causes changed rows to be sent to the database as soon as the user moves to a new row in the recordset. Deferred flushing sends the rows to the database only when the user commits the changes. If there are any problems with the data in a row, such as data which is too big or a violation of an integrity constraint, your application will find out about it when the rows are sent to the database.
Unfortunately, OPO forces you to use immediate flushing in a bound container. You can set up deferred flushing for a standalone recordset.
OPO also ‘supports’ optimistic and pessimistic locking. With optimistic locking, a row is not locked until a user commits the row. Since locks are used to prevent other users from changing the data in a row, you are optimistic that no one will change your data. With pessimistic locking, a row is locked as soon as the user starts to change the data. You are pessimistic about the chances that no other user will change your data, so you will prevent them from doing it from the get go.
OPO only supports pessimistic locking in version 1.0. The capability provided with the CompareOnLock property helps to recognize if there is a problem with a potential change in row values, but having the ability to combine this nifty feature with optimistic locking sure would be nice.
