WAS v8.5 > Develop applications > Develop Work area

Work area partition service

The work area partition service is an extension of the work area service that enables the creation of multiple custom work areas. The work area partition service is an optional service to users. Any user that currently uses the work area service and the UserWorkArea partition can continue using it in the same manner. The UserWorkArea partition is created automatically (if it has not been disabled) by the work area partition service. By allowing a user the option to create their own work area partition through the work area partition service, they can have more control over configuration and access to their partition.

The work area partition service is essentially a factory for creating instances of the UserWorkArea interface. Applications interact with work areas using the UserWorkArea interface and its implementation. This interface defines all of the methods used to create, manipulate, and complete work areas. The work area partition service allows users to create their own named instance of the UserWorkArea interface. Each named instance is called a user-defined work area partition, or partition for short. Each instance of the UserWorkArea interface (partition) is separate from other user-defined partitions. Furthermore, we can configure a partition with various options to provide qualities of service that are unique to a use case for an individual user. Any configuration option made within the work area partition service panel does not affect the work area service.

Unlike the UserWorkArea partition, which is publicly known, work areas created by the work area partition service are accessible to, and known only by, the creator. However, the work area partition service does not strictly enforce that a partition is accessed and/or operated on exclusively by the partition creator. There are no limitations should the creator want to publish their work area partition and make it publicly available by binding their partition reference in Java naming or by other means. However, the work area partition service does try to hide a partition as much as possible should a user not want others to know about a certain partition. The work area partition service does not enable a person to determine or query the names of all the partitions that have been created; however, it does not restrict the partitions from being accessed by users other than the creator of that partition. The context of a partition, such as the UserWorkArea partition or a user-defined partition, is scoped to a single thread and is not accessible by multiple threads.

The work area partition reference that is returned to a user implements javax.naming.Referenceable and com.ibm.websphere.UserWorkArea, therefore a user can bind their partition into a name to make their partition publicly available. An alternative to using Java naming to bind and access the partition is to use the work area partition manager interface. Anyone can access the work area partition manager interface; therefore, if a user wants to make their partition publicly available, they simply need to publish their partition name. Other users can then call the getWorkAreaPartition method on the work area partition manager interface with the published name.

The WorkAreaPartitionManager.createWorkAreaPartition method can only be used from a Java EE client. To create a work area partition on the server side, one must use the dmgr console. On the server side a work area partition must be created during server startup because each partition needs to be register with the appropriate Web and EJB collaborators before the server has started. Custom work area partitions are created by the work area partition service and defined by the UserWorkArea interface.

The work area partition service also allows a user to configure partitions with additional properties that are not available on the UserWorkArea partition, such as bidirectional propagation of work area partition context and deferred attribute serialization. These properties are available as configuration properties when creating a partition. For a complete list of the configuration properties available when creating a partition, see the "Configurable Work Area Partition Properties" section in the Work area partition manager interface article. The properties are defined as follows:


Bidirectional propagation of work area context

If a remote invocation is issued from a thread associated with a work area, a copy of the work area is automatically propagated to the target object, which can use or ignore the information in the work area as necessary. If the calling application has a nested work area associated with it, a copy of the nested work area and all its ancestors are propagated to the target application. The target application can locally modify the information, as allowed by the property modes, by creating additional nested work areas; this information is propagated to any remote objects that it invokes.

Whether context changes propagate back to a calling application from a remote application depends on the configuration of the work area partition. If a user creates a partition to be bidirectional by selecting the Bidirectional property during partition creation, changes made by a remote application propagate back to the calling application, meaning that changes made to the work area context by a downstream process will propagate back upstream. The UserWorkArea partition is not configured (and can never be configured) to be bidirectional, therefore context changes only flow to downstream processes and do not propagate back upstream.


Example: Bidirectional propagation of work area context

Whether context changes propagate back to a calling application from a remote application depends on the configuration of the work area partition. If a user creates a bidirectional partition, changes made by a remote application propagate back to the calling application. Changes made to the work area context by a downstream process propagate back upstream. The figure Distribution of work area context when configured for bidirectional propagation illustrates this relationship during a remote call to the server. For this illustration, the client and server must have created a partition with the same name.

Figure 1. Distribution of work area context when configured for bidirectional propagation. This figure illustrates the distribution of work area context when the service is configured for bidirectional propagation.

When the client makes a remote call to the server, the server receives the context set by the client process. The server then can make changes to this context or add to it. In this illustration, the server overwrites the value at key1, removes the property at key2, and adds two new properties at key5 and key6. When the server application returns to the client, the work area context is propagated back to the client and unmarshalled. The current work area is then updated with the new context. Note that if the partition is not configured as bidirectional and the server tries to change or remove context in Work Area 1, it receives a com.ibm.websphere.workarea.NotOriginator exception because the client was the originator of the work area. The server can retrieve the context in Work Area 1. This is the main distinction between bidirectional propagation of context and non-bidirectional propagation.


Example: Bidirectional propagation of nested work area context

If a remote application needs to add context to a work area that is only used by itself or any other remote objects, the remote application must begin another work area. By beginning a new work area, the additional context is scoped to that application and does not flow back to the calling application. The major benefit of nesting work areas is that nesting work areas allows an application to scope work area context to a given application. Taking the illustration one step further, if the server has begun a work area before overwriting the value at key1, removing the property at key2, or adding new properties at key5 and key6; those changes would not have propagated back to the client. This is shown in the figure Distribution of nested work area context when configured for bidirectional propagation. We can also see from this figure the client does not receive the context from the nested work area started by the server.

Figure 2. Distribution of nested work area context when configured for bidirectional propagation. This figure illustrates the distribution of nested work area context when the service is configured for bidirectional propagation.


Deferred attribute serialization of work area context

By default, on each set operation the attribute set into a work area is automatically serialized by the work area service. On each subsequent get operation on that same attribute it is deserialized and returned to the requester. This gives the work area service complete control of the attribute such that any changes to a mutable object are not reflected in the work area's copy of the attribute unless a user specifically resets the attribute into the work area. However, this can potentially lead to excessive serialization and deserialization.

Excessive serialization and deserialization can result in observable performance degradation under heavy load. The deferred attribute serialization configuration property is a caching feature that reduces serialization and deserialization operations. When deferred attribute serialization is enabled in a client or server process by selecting the Deferred Attribute Serialization field during the creation of the work area, attributes set into the work area service are not automatically serialized during the set operation. Rather, a reference to the attribute is stored in the work area. If the attribute is mutable, then changes to the object are reflected in the work area's reference to that attribute. When a get operation is performed on that attribute, the reference to that object is returned and no deserialization is performed.

Attributes are not serialized until the thread with which the attribute is associated makes a remote IIOP invocation. At that point, the attribute is serialized and the serialized form of the attribute is cached. If the attribute is not reset into the work area, changes to the original attribute are still reflected within the attribute contained within the work area because the work area still holds a cached reference to the original object. However, if the work area has not been told the attribute has changed by resetting the attribute into the work area, subsequent remote requests continue to use the cached serialized version of the attribute and direct changes to the mutable attribute are not propagated. This is an important distinction between enabling and not enabling the deferred attribute serialization configuration property, and a user must pay close attention to this difference and how mutable objects are handled when enabling deferred attribute serialization. The work area service releases cached references and cached serialized versions of attributes when any of the following conditions occur:


Partition context propagation across process boundaries

Work area context automatically propagates from client to server when a client makes a remote call to a server. For example, if a client is configured with three different work area partitions when it makes a remote call to a server, server1, the context associated with each partition on the client thread propagates to server1. If the same three partitions have been created on server1, the context is unmarshalled to the appropriate partition. However, if none or only a few of the three partitions have been created on server1, only the context associated with a partition that is resident on both the client and server is unmarshalled. The context associated with a partition not resident on server1 is still resident on server1 but is not accessible. The context associated with partitions that are not resident on server1 must remain resident on server1 in case another remote call is made to a different server. Going one step further, if server1 makes a call to another server, server2, that has the same partitions as the client, server2 receives the context for the partitions that were not resident on server1. Any partitions that reside on server1 that did not reside on the client now have their context propagated to server2.

For more information about work area, see the com.ibm.websphere.workarea package in the Application Programming Interface (API). The generated API documentation is available in the information center table of contents from the path Reference > APIs - Application Programming Interfaces.


Related concepts:

Nested work areas


Related


Configure work area partitions


Reference:

The Work area partition manager interface
Example: Using the work area partition manager


+

Search Tips   |   Advanced Search