ManagedReference will typically result in an {@link ObjectIOException} being thrown when the current transaction commits. Managed objects that are bound to names, and any managed objects they refer to directly or indirectly, are stored by the DataManager. It is up to the application to determine when managed objects are no longer needed and to remove them explicitly from the DataManager using the {@link #removeObject removeObject} method.
Managed objects are in one of the following states with respect to the data manager:
Passing a transient object to {@code setBinding}, {@code createReference}, or {@code getObjectId} creates a new entry for theobject in the data manager. Calling {@code removeObject} or {@link #markForUpdate markForUpdate} on a transient object does not change thestate of the object. If a transient object implements {@link ManagedObjectRemoval}, though, then calling {@code removeObject} willcause its {@link ManagedObjectRemoval#removingObject removingObject}method to be called.
Passing a persistent object to {@code setBinding}, {@code createReference}, {@code markForUpdate}, or {@code getObjectId} does notcreate a new entry for that object in the data manager, but rather reuses the existing one. Calling {@code removeObject} on a persistentobject removes it from the data manager, meaning it will no longer be stored persistently, and changes its state to removed. Note that a managed object made persistent in the current transaction is automatically marked for update, so there is no need to call {@code markForUpdate} for such objects, in particular in theirconstructors.
Only persistent managed objects can become removed; calling {@code removeObject} on a transient managed object leaves it as a transientobject. Passing a removed managed object to {@code setBinding}, {@code removeObject}, {@code markForUpdate}, {@code createReference}, or {@code getObjectId}, as well as calling {@code ManagedReference.get} or {@code ManagedReference.getForUpdate} on a reference to the removed object,will cause a {@link ObjectNotFoundException} to be thrown, if the systemhas tracked the object's removed state.
Passing a stale object to {@code setBinding}, {@code removeObject}, {@code markForUpdate}, {@code createReference}, or {@code getObjectId}, as well as calling {@code ManagedReference.get} or {@code ManagedReference.getForUpdate} on a reference to the stale object, willcause a {@link TransactionNotActiveException} to be thrown, if thesystem has tracked the object's stale state.
Because storing a managed object in a name binding or creating a managed reference to it causes the object to be stored in data manager, applications should insure that they remove such objects if they end up not referring to them persistently. The {@code removeObject} method does not throwexceptions when called on a transient object, so applications should call {@code removeObject} whenever there is an object that may have becomepersistent and they are sure is no longer used.
Some implementations may need to be notified when managed objects and the objects they refer to are modified, while other implementations may be configurable to detect these modifications automatically. Applications are always permitted to mark objects that have been modified, and doing so may produce performance improvements regardless of whether modifications are detected automatically. @see AppContext#getDataManager @see ManagedObject @see ManagedReference @see Serializable
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |