Telerik OpenAccess ORM

This property controls whether persistent class instances retain their values after commit of the transaction and if read access is allowed. By default it is set to true. However, regardless of this setting, objects are refreshed from the data store the next time the object is accessed within an active transaction.

This property controls whether the values of objects are restored to their original values when a transaction (or one particular nesting level) is rolled back. By default it is set to false.

As described earlier in this chapter, OpenAccess ORM uses optimistic concurrency control by default (refer to Concurrency Control Algorithms for more information about the various concurrency control mechanisms). This means that OpenAccess ORM does not validate read (but unmodified) objects at commit time, and therefore it is possible that if an object is read inside a transaction, it might be changed in the database, while the transaction is running.

So, in order to avoid long-living stale objects, OpenAccess ORM will refresh such objects if they are accessed in a subsequent transaction. This happens on the first access to such objects. Thus, only short-living stale objects are possible, at the cost of an SQL call for refreshing the object in a subsequent transaction.

It is possible to have more control over this refreshing behavior, by disabling the automatic refresh function, which can be done as shown below:

	Copy Code
scope.TransactionProperties.RefreshReadObjectsInNewTransaction = false;

The advantage of using this is that objects can keep their data for a long time, without the need for executing an SQL Statement again.

However, if you enable "no automatic refreshes" then you are responsible for avoiding stale data, i.e. you will need to call Refresh() or Evict() at appropriate times. Therefore, please use this with care, since read (but not modified) objects, will not be refreshed automatic`ally in new transactions of the same ObjectScope, i.e., if an object is fetched from the database in the first transaction and is subsequently never explicitly refreshed, evicted or modified in subsequent transactions, it will still have the values from the first transaction.

This property determines the concurrency settings of a transaction. The default is TransactionMode.OPTIMISTIC|TransactionMode.NO_LOST_UPDATES.

This property allows the user to specify that every Commit()/Rollback() of a transaction will start a new transaction immediately. Therefore, the user does not need to call Begin(), and one can work with just Commit() and Rollback() calls. In other words, there is always a started transaction. This is regardless of a failure of a Commit() [the next transaction will yet be started].

This is especially useful for multithreaded applications, i.e., working with multiple threads in one object scope by setting the <option.Multithreaded> to "true", since this allows an automatic synchronized Commit() + Begin().

This property determines whether a transaction commit or flush, should fail at the first failure. When this property is set to true (default value), the transaction will fail on the occurrence of the first OptimisticVerificationException. When this property is set to false the IObjectScope will collect all the failures, i.e., the commit or flush will continue and collect all the OptimisticVerificationExceptions that occur. It might be time consuming to collect all the failures, therefore this property is set to true by default.

This property should be set to false only when the information about failing objects is necessary, since it might be very time consuming to collect all the failures.