- All Implemented Interfaces:
Scope implementation, delegating to
TransactionSynchronizationManager's resource binding mechanism.
this transaction scope is not registered by default in common contexts. Instead,
you need to explicitly assign it to a scope key in your setup, either through
or through a
- Juergen Hoeller
- See Also:
Method SummaryModifier and TypeMethodDescriptionReturn the object with the given name from the underlying scope,
creating itif not found in the underlying storage mechanism.Return the conversation ID for the current underlying scope, if any.
voidRegister a callback to be executed on destruction of the specified object in the scope (or at destruction of the entire scope, if the scope does not destroy individual objects but rather only terminates in its entirety).Remove the object with the given
namefrom the underlying scope.Resolve the contextual object for the given key, if any.
getReturn the object with the given name from the underlying scope,
creating itif not found in the underlying storage mechanism.
This is the central operation of a Scope, and the only operation that is absolutely required.
removeRemove the object with the given
namefrom the underlying scope.
nullif no object was found; otherwise returns the removed
Note that an implementation should also remove a registered destruction callback for the specified object, if any. It does, however, not need to execute a registered destruction callback in this case, since the object will be destroyed by the caller (if appropriate).
Note: This is an optional operation. Implementations may throw
UnsupportedOperationExceptionif they do not support explicitly removing an object.
- Specified by:
name- the name of the object to remove
- the removed object, or
nullif no object was present
- See Also:
registerDestructionCallbackRegister a callback to be executed on destruction of the specified object in the scope (or at destruction of the entire scope, if the scope does not destroy individual objects but rather only terminates in its entirety).
Note: This is an optional operation. This method will only be called for scoped beans with actual destruction configuration (DisposableBean, destroy-method, DestructionAwareBeanPostProcessor). Implementations should do their best to execute a given callback at the appropriate time. If such a callback is not supported by the underlying runtime environment at all, the callback must be ignored and a corresponding warning should be logged.
Note that 'destruction' refers to automatic destruction of the object as part of the scope's own lifecycle, not to the individual scoped object having been explicitly removed by the application. If a scoped object gets removed via this facade's
Scope.remove(String)method, any registered destruction callback should be removed as well, assuming that the removed object will be reused or manually destroyed.
- Specified by:
name- the name of the object to execute the destruction callback for
callback- the destruction callback to be executed. Note that the passed-in Runnable will never throw an exception, so it can safely be executed without an enclosing try-catch block. Furthermore, the Runnable will usually be serializable, provided that its target object is serializable as well.
- See Also:
resolveContextualObjectResolve the contextual object for the given key, if any. E.g. the HttpServletRequest object for key "request".
getConversationIdReturn the conversation ID for the current underlying scope, if any.
The exact meaning of the conversation ID depends on the underlying storage mechanism. In the case of session-scoped objects, the conversation ID would typically be equal to (or derived from) the
session ID; in the case of a custom conversation that sits within the overall session, the specific ID for the current conversation would be appropriate.
Note: This is an optional operation. It is perfectly valid to return
nullin an implementation of this method if the underlying storage mechanism has no obvious candidate for such an ID.