Preferred Solution: This behaviour has been changed in
WebSphere Process Choreographer Version 5.0.2. So, best solution is to
upgrade to WebSphere Process Choreographer 5.0.2 (WebSphere Application
Server Enterprise 5.0.2).
If, however, you are not able to upgrade, there is a workaround
addressing this problem:
As mentioned, the performance bottleneck is the Java Serialization /
Deserialization. Two workarounds for this problem are descried below:
(1) Serialization / Deserialization can be avoided if the
objects that are copied implement the java.lang.Cloneable
interface:
public class AClass implements java.io.Serializable,
java.lang.Cloneable {
...
public Object clone() {
Object clone;
// do the clone
return clone;
}
Now, if an instance of type AClass is used in the Global Data Context
(for example, as input parameter), passing it to a Java Snippet activity
invokes the clone() method instead of serializing / deserializing it. In
general, this is much faster.
(2) There is another possibility that is probably the fastest
one. Consider the following implementation of the clone() method:
public Object clone() {
return this;
}
Using the clone() method this way returns the instance itself. Hence,
no copy (and therefore, no memory allocation, no new instances, no copy
...) is done. This technique is significantly faster than all the other
methods.
If you want to use this method, be aware of the following:
- you are no longer using copies. You are using
references. So, no write-back to the Global Data Context is necessary (all
changes to the object are immediately visible).
- you bypass a design pattern of WebSphere Process
Choreographer 5.01 (use of copies in activities)
|