You can migrate an application with a WebSphere Application Server
Version 5.x application profile to a version 6 application profile. You might
want to migrate because the application profiling function works under a different
concept in version 6 and a major difference exists between Version 5.x and
Version 6 in the scoping of a task name.
About this task
For the implications of using Java 2 platform, Enterprise Edition
(J2EE) 1.3 applications with an application profile configuration from WebSphere
Application Server Version 5.x on Version 6, see Running Version 5 Application Profiles on Version 6 .
In Version 5.x, a task name could
be assigned to a bean, web, or client method. When a method was invoked that
had a task name configured on it, either that task name became the active
task name (known as 'run as specified') or the caller's task name, should
one exist, became the active task name (known as 'run as caller'). In Version
6, the application profiling function works under the unit of work (UOW) concept.
UOW in this case means either a transaction or an ActivitySession. This means
that the task name on a method is used only when a UOW is begun, because of
that method being invoked. This gives it a more predictable data access pattern
based on the active unit of work. To be more specific, this approach ensures
that a bean type with only one configured access intent is loaded within a
UOW, because a bean is configured with only one access intent within an application
profile. This configured access intent for a bean type is determined at assembly
time and is enforced by the Application Profile service. In Version 5.x, a
bean type could be loaded in different access intents and cause deadlock problems
within a UOW.
A major difference between Version 5.x and Version 6
is with the scoping of a task name. In Version 5.x, a task is not necessarily
associated with a UOW. In Version 6, a task name is always associated with
a UOW and that task name does not change for the duration of that UOW. When
a UOW associated with a method is begun because of that method being invoked,
if a task name is associated with the method then that task name is used to
name the UOW. A task assigned to a UOW is considered a named UOW. If a task
name is not associated with the method that began the UOW, then a default
access intent is used and the UOW is unnamed. A UOW can only be named when
the UOW is begun. Any task names associated with a method are ignored if that
method does not begin a UOW (either container managed or component managed).
To
migrate a Version 5.x application to use version 6 application profile functionality
do the following:
- Configure a UOW on a method.
In
Version 5.x it wasn't necessary to associate a task with a UOW. In Version
6, a task can only be associated with a UOW when that UOW is begun. Therefore,
the first step to convert a Version 5.x application to Version 6 is to define
a UOW on any method that has a task name (and eventually an Application Profile)
associated with it. A UOW can either be container managed or component managed
and can either be a transaction or an ActivitySession. Developing components to use transactions describes the two types of transaction (container
managed and component managed) and how to create them. Using the ActivitySession service describes how to use and create an ActivitySession
UOW.
- Associate a method level task name with the same methods used to
define the UOW you just created.
When a method is called that
causes a UOW to begin, if a task name is associated with the same method then
that task name becomes the active task name and is associated with the UOW.
Therefore, a task name needs to be defined on a method that participates in
a UOW and that needs an Application Profile associated with it. A task can
be associated with a method either declaratively through an application's
deployment descriptor or programmatically through the TaskNameManager API.
Assembling applications for application profiling describes how to configure task names
either declaratively or programmatically.
- Reassign 'run as caller' tasks. In Version 5.x, you
could define a container task to be either 'run as caller' or 'run as specified'.
In the 'run as caller case', if the configured methods are invoked with an
associated task, the method is executed with the imported (caller's) task.
If a method is invoked by a request that is not associated with a task, the
method continues to execute without a task. In the 'run as specified' case,
the configured methods are never invoked with an imported (caller's) task.
Instead, the method executes as the specified task name.
In Version 6,
these two "run as" options have explicitly been removed yet are still implied.
In other words, when a user defines a method with a task name, the user is
specifying a task name to be used when the method is invoked. This is similar
to 'run as specified' in Version 5.x. However, it is not exactly 'run
as specified' because in Version 6 a task name can only be associated with
a UOW when that UOW is begun. In other words, even if a method has a task
name associated with it in Version 6, that task name is ignored if there is
already a UOW, or if the method does not cause a UOW to begin. In Version
5.x, a 'run as specified' task defined on a method always became the active
task name when the method was invoked.
The 'run as caller' option
of Version 5.x is also implicitly available in Version 6, although not explicitly
stated. When a method (callee) is invoked by another method (caller) that
has a UOW associated with it, the callee is associated with the caller's UOW
if the callee does not begin a new UOW. In other words, the callee runs with
the caller's task. The name of the UOW is the task name associated with the
callee, even if the callee has its own task name specified. Keep in mind that
the UOW could be unnamed, in which case no task name is associated with the
caller or callee.
- Optional: Remove method level access intent.
In Version 6.0, method level access intent has been deprecated. It is
suggested that you remove method level access intent from your applications.
In its place assign task names to a method and then assign the task name to
an Application Profile with the necessary access intent.