An object of a persistent class managed by the Persistence Service can have one of seven different management states. The state of the object affects what
methods of the Persistence Service can be performed on it. The methods of the interface IF_OS_CA_INSTANCE provide information on the state of managed objects.The following constants of the type group OSCON return the state of the object:
|
Constant |
Value |
State |
|
OSCON_OSTATUS_NOT_LOADED |
0 |
The object exists as a representative object for a persistent object. At present, no data has been loaded from the database. |
|
OSCON_OSTATUS_NEW |
1 |
The object is persistent and is newly created. |
|
OSCON_OSTATUS_LOADED |
2 |
The object is persistent and has been loaded completely. |
|
OSCON_OSTATUS_CHANGED |
3 |
The object is persistent and has been changed. |
|
OSCON_OSTATUS_DELETED |
4 |
The object is persistent and has been deleted. |
|
OSCON_OSTATUS_TRANSIENT |
10 |
The object is transient. |
|
OSCON_OSTATUS_LOADING |
12 |
The object is being loaded at this moment. |
The states 0 to 4 describe persistent objects with a connection to the database. An object in state 10 is managed by the Persistence Service but has no connection to the database.
An object in state 12 is in transition to the state OSCON_OSTATUS_LOADED. This state can be observed only in the method INIT of the interface IF_OS_STATE, so it will not be listed in the following tables.
The table below indicates the methods of the Persistence Service that can be performed on objects in different states, and how they affect the state of the managed object. The last line shows the effect of the statement COMMIT WORK.
|
- |
0 |
1 |
2 |
3 |
4 |
10 |
|
|
CREATE_PERSISTENT |
1 |
3 |
exc |
exc |
exc |
3 |
exc |
|
DELETE_PERSISTENT |
- |
4 |
0 |
4 |
4 |
4 |
exc |
|
GET_PERSISTENT |
2 |
2 |
1 |
2 |
3 |
exc |
exc |
|
GET_attribute |
exc |
2 |
1 |
3 |
3 |
exc |
10 |
|
SET_attribute |
exc |
3 |
1 |
3 |
3 |
exc |
10 |
|
REFRESH_PERSISTENT |
exc |
0 |
exc |
0 |
exc |
exc |
exc |
|
RELEASE |
exc |
- |
exc |
- |
exc |
exc |
exc |
|
CREATE_TRANSIENT |
10 |
exc |
exc |
exc |
exc |
exc |
exc |
|
GET_TRANSIENT |
exc |
exc |
exc |
exc |
exc |
exc |
10 |
|
COMMIT WORK |
- |
0 |
0 |
0 |
0 |
- |
10 |
All the above methods belong to the class actor (see
Components of the Persistence Service) except GET_attribute and SET_attribute. For simplicity’s sake, we have summarized the class and interface methods by using typical names for them. GET_attribute and SET_attribute are methods of the persistent class.The numbers reflect the management states. For example, the DELETE_PERSISTENT method shifts a persistent object from the state 0, 2, 3, or 4 to the state 4.
The dash indicates that an object of a persistent class is available but cannot be managed. A situation like this may occur, for example, if the system deletes a persistent object by passing a reference to the DELETE_PERSISTENT method. The COMMIT WORK statement deletes the object from the database and it is no longer managed. However, it still exists in the internal session until all references to it are also deleted.
As you can see from the table, the DELETE_PERSISTENT, GET_PERSISTENT, and REFRESH_PERSISTENT methods can work only with persistent objects in a state from 0 to 4, while GET_TRANSIENT can work only with transient objects in the state 10.
If you try to apply a method to a management state inappropriately, you will trigger an
exception exc.