org.omg.PortableServer.POAManagerPackage
Class State

java.lang.Object
  org.omg.PortableServer.POAManagerPackage.State

All Implemented Interfaces:

java.io.Serializable, IDLEntity

public final class State
extends java.lang.Object
implements IDLEntity

See Also:

Serialized Form

Field Summary

static int	_ACTIVE Active State When a POA manager is in the active state, the associated POAs will receive and start processing requests (assuming that appropriate thread resources are available). Note that even in the active state, a POA may need to queue requests depending upon the ORB implementation and resource limits.
static int	_DISCARDING Discarding State When a POA manager is in the discarding state, the associated POAs will discard all incoming requests (whose processing has not yet begun).
static int	_HOLDING Holding State When a POA manager is in the holding state, the associated POAs will queue incoming requests.
static int	_INACTIVE Inactive State The inactive state is entered when the associated POAs are to be shut down.
static State	ACTIVE Active State When a POA manager is in the active state, the associated POAs will receive and start processing requests (assuming that appropriate thread resources are available). Note that even in the active state, a POA may need to queue requests depending upon the ORB implementation and resource limits.
static State	DISCARDING Discarding State When a POA manager is in the discarding state, the associated POAs will discard all incoming requests (whose processing has not yet begun).
static State	HOLDING Holding State When a POA manager is in the holding state, the associated POAs will queue incoming requests.
static State	INACTIVE Inactive State The inactive state is entered when the associated POAs are to be shut down.

Method Summary

static State	from_int(int _vis_value)
int	value()

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

_HOLDING

public static final int _HOLDING

Holding State When a POA manager is in the holding state, the associated POAs will queue incoming requests. The number of requests that can be queued is an implementation limit. If this limit is reached, the POAs may discard requests and return the TRANSIENT system exception to the client to indicate that the client should reissue the request. (Of course, an ORB may always reject a request for other reasons and raise some other system exception.)
In addition, when a POA manager is in the holding state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be queued, as described in the previous paragraph.
A POA manager can legally transition from the holding state to either the active, discarding, or inactive state by calling the activate, discard_requests, or deactivate operations, respectively.
The POA enters the holding state through the use of the hold_requests operation when in the active or discarding state. A POA manager is created in the holding state.

See Also:

Constant Field Values

_ACTIVE

public static final int _ACTIVE

Active State When a POA manager is in the active state, the associated POAs will receive and start processing requests (assuming that appropriate thread resources are available).
Note that even in the active state, a POA may need to queue requests depending upon the ORB implementation and resource limits.
The number of requests that can be received and/or queued is an implementation limit. If this limit is reached, the POA should return a TRANSIENT system exception to indicate that the client should re-issue the request. A user program can legally transition a POA manager from the active state to either the discarding, holding, or inactive state by calling the discard_requests, hold_requests, or deactivate operations, respectively.
The POA enters the active state through the use of the activate operation when in the discarding or holding state.

See Also:

Constant Field Values

_DISCARDING

public static final int _DISCARDING

Discarding State When a POA manager is in the discarding state, the associated POAs will discard all incoming requests (whose processing has not yet begun). When a request is discarded, the TRANSIENT system exception must be returned to the client-side to indicate that the request should be re-issued. (Of course, an ORB may always reject a request for other reasons and raise some other system exception.)
In addition, when a POA manager is in the discarding state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be discarded, as described earlier.
The primary purpose of the discarding state is to provide an application with flow-control capabilities when it determines that an object's implementation or POA is being flooded with requests. It is expected that the application will restore the POA manager to the active state after correcting the problem that caused flow-control to be needed.
A POA manager can legally transition from the discarding state to either the active, holding, or inactive state by calling the activate, hold_requests, or deactivate operations, respectively.
The POA enters the discarding state through the use of the discard_requests operation when in the active or holding state.

See Also:

Constant Field Values

_INACTIVE

public static final int _INACTIVE

Inactive State The inactive state is entered when the associated POAs are to be shut down. Unlike the discarding state, the inactive state is not a temporary state. When a POA manager is in the inactive state, the associated POAs will reject new requests. The rejection mechanism used is specific to the vendor.
The GIOP location forwarding mechanism and CloseConnection message are examples of mechanisms that could be used to indicate the rejection. If the client is co-resident in the same process, the ORB could raise the OBJ_ADAPTER exception to indicate that the object implementation is unavailable. In addition, when a POA manager is in the inactive state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be rejected, as described in the previous paragraph.
The inactive state is entered using the deactivate operation. It is legal to enter the inactive state from either the active, holding, or discarding states. If the transition into the inactive state is a result of calling deactivate with an etherealize_objects parameter of TRUE - the associated POAs will call etherealize for each active object associated with the POA once all currently executing requests have completed processing (if the POAs have the RETAIN and USE_SERVANT_MANAGER policies).
If a servant manager has been registered for the POA, the POA will get rid of the object. If there are any queued requests that have not yet started executing, they will be treated as if they were new requests and rejected. FALSE - No deactivations or etherealizations will be attempted.

See Also:

Constant Field Values

HOLDING

public static final State HOLDING

Holding State When a POA manager is in the holding state, the associated POAs will queue incoming requests. The number of requests that can be queued is an implementation limit. If this limit is reached, the POAs may discard requests and return the TRANSIENT system exception to the client to indicate that the client should reissue the request. (Of course, an ORB may always reject a request for other reasons and raise some other system exception.)
In addition, when a POA manager is in the holding state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be queued, as described in the previous paragraph.
A POA manager can legally transition from the holding state to either the active, discarding, or inactive state by calling the activate, discard_requests, or deactivate operations, respectively.
The POA enters the holding state through the use of the hold_requests operation when in the active or discarding state. A POA manager is created in the holding state.

ACTIVE

public static final State ACTIVE

Active State When a POA manager is in the active state, the associated POAs will receive and start processing requests (assuming that appropriate thread resources are available).
Note that even in the active state, a POA may need to queue requests depending upon the ORB implementation and resource limits.
The number of requests that can be received and/or queued is an implementation limit. If this limit is reached, the POA should return a TRANSIENT system exception to indicate that the client should re-issue the request. A user program can legally transition a POA manager from the active state to either the discarding, holding, or inactive state by calling the discard_requests, hold_requests, or deactivate operations, respectively.
The POA enters the active state through the use of the activate operation when in the discarding or holding state.

DISCARDING

public static final State DISCARDING

Discarding State When a POA manager is in the discarding state, the associated POAs will discard all incoming requests (whose processing has not yet begun). When a request is discarded, the TRANSIENT system exception must be returned to the client-side to indicate that the request should be re-issued. (Of course, an ORB may always reject a request for other reasons and raise some other system exception.)
In addition, when a POA manager is in the discarding state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be discarded, as described earlier.
The primary purpose of the discarding state is to provide an application with flow-control capabilities when it determines that an object's implementation or POA is being flooded with requests. It is expected that the application will restore the POA manager to the active state after correcting the problem that caused flow-control to be needed.
A POA manager can legally transition from the discarding state to either the active, holding, or inactive state by calling the activate, hold_requests, or deactivate operations, respectively.
The POA enters the discarding state through the use of the discard_requests operation when in the active or holding state.

INACTIVE

public static final State INACTIVE

Inactive State The inactive state is entered when the associated POAs are to be shut down. Unlike the discarding state, the inactive state is not a temporary state. When a POA manager is in the inactive state, the associated POAs will reject new requests. The rejection mechanism used is specific to the vendor.
The GIOP location forwarding mechanism and CloseConnection message are examples of mechanisms that could be used to indicate the rejection. If the client is co-resident in the same process, the ORB could raise the OBJ_ADAPTER exception to indicate that the object implementation is unavailable. In addition, when a POA manager is in the inactive state, the adapter activators registered with the associated POAs will not get called. Instead, requests that require the invocation of an adapter activator will be rejected, as described in the previous paragraph.
The inactive state is entered using the deactivate operation. It is legal to enter the inactive state from either the active, holding, or discarding states. If the transition into the inactive state is a result of calling deactivate with an etherealize_objects parameter of TRUE - the associated POAs will call etherealize for each active object associated with the POA once all currently executing requests have completed processing (if the POAs have the RETAIN and USE_SERVANT_MANAGER policies).
If a servant manager has been registered for the POA, the POA will get rid of the object. If there are any queued requests that have not yet started executing, they will be treated as if they were new requests and rejected. FALSE - No deactivations or etherealizations will be attempted.

Method Detail

value

public int value()

from_int

public static State from_int(int _vis_value)