Shared Objects - Advanced Features 

MULTI_ATTACH – Avoiding Two-Way Blocking

When programs from two different internal sessions require several exclusive locks, it is easy for deadlocks to arise.

Two programs A and B in different internal sessions both attempt to obtain exclusive locks for the areas 1 and 2; each does so in a different order. This results in the following situation: While program A obtains the lock for area 1 and holds it until it also gets the lock for area 2, program B waits for the lock for area 1, which program A already has, and itself holds the lock for area 2, which program is waiting for. Programs A and B would thus continue to block one another.

The MULTI_ATTACH method prevents such situations: You must use this method if you want to connect to more than one area from an internal session. This method then ensures that you either obtain all the required locks or none of them – that is, a non-atomic operation is made atomic. In this way, you will never hold one or more locks while waiting for others.

Synchronizing Shared Objects Areas and the Database

In some cases, you have to ensure that the data in shared object areas is synchronized with data on the database. If you connect to an area, change the data there with DETACH_COMMIT, and the changes to the relevant database data then fails and a rollback takes place, this would result in inconsistencies between the data on the database on that in the shared objects area.

In these cases, you should use transactional areas. If you use the DETACH_COMMIT command here, any changes to data in the transactional area only come into effect at the next database commit. Until then, the changes are deferred.

Making Changes in Shared Object Areas Available Server-Wide

By making the appropriate settings for the framework, you can make data from one area of a server available on other servers of the same system. Once the data is changed on one server, the other servers are informed that this area was invalidated.

You must then make sure that an area constructor for automatic area building is called in the case of any read requests to an invalidated area. The framework supports you in that changes to areas are propagated over multiple servers.

Automatic Area Building

You can also specify that this automatic area build take place if no active instance of an area exists when a read request takes place.

Lifetime and Displacement of Shared Object Areas

At design time, you can set the lifetime of the contents of a shared objects memory area using transaction SHMA:

·        Up to a specified time at which the contents are deleted

·        Up to a specified time at which the contents are reloaded

·        Until a specified time has passed without any read accesses taking place

·        Unlimited – that is, until the application server is shut down or the area is explicitly invalidated

 

You can also define that specific areas are to be displaced if the memory for all areas, which you defined, or the total memory for one area is exceeded.

Client Dependency

At design time, you can specify that shared object areas are to be client-specific. This means that every client sees only its instances.