Show TOC

Component documentationTransactional Area Locate this document in the navigation structure

 

An area instance version of a transactional area is not active immediately after a change lock is removed using the DETACH_COMMIT method of the area handle; it becomes active after the next database commit instead. Between the time when the lock is removed and the database commit, the area instance version looks like it is being built. No new change locks can be set on the area instance, and read locks access the previous active version. In the case of non-transactional areas, the state of the area instance version is set to active as soon as the DETACH_COMMIT method is executed.

With transactional areas, the methods FREE_AREA, FREE_INSTANCE, INVALIDATE_AREA, and INVALIDATE_INSTANCE of the area class have a parameter called AFFECT_SERVER that can be used to control the cross-server invalidation.

Transactional areas enable data or objects in the area instance versions to join such areas to database contents.

Caution Caution

To ensure that the reference between database content and shared objects is not damaged, changes to the shared objects should be made only in contexts in which the database changes were also made in the current application. During updating, for example, changes to the shared objects should only be made while the corresponding update functional module is being executed.

End of the caution.