This section summarizes the managed class changes that are supported - both transparent and non-transparent. Unsupported changes are summarized in the section called “Unsupported changes”. The upgrade utility discussed in the section called “Upgrade utility” audits all of the changes summarized in these sections and provides details on any incompatible changes being made.
Non-managed classes can be changed as required. These changes have no impact on other nodes in the cluster.
Managed classes being changed must be partitioned classes in a partition that has at least one replica node. This is to ensure that there is no data loss during the upgrade process. An attempt to upgrade a non-partitioned class, or a partitioned class without a replica node, will fail during the upgrade process. See the TIBCO ActiveSpaces® Transactions Administration for details on the upgrade process.
Transparent changes to application classes do not require any application support. TIBCO ActiveSpaces® Transactions supports these changes transparently:
Adding a field - the default value of the field is zero or empty, depending on the field type, when populating the field on the node with the new version.
Removing a field - the default value of the field is set to zero or empty, depending on the field type, before sending it to a node with a down-rev version.
Removing one or more keys.
Removing fields from an existing multi-part key definition.
Changing a field modifier from a non-static to a static final field (equivalent to removing a field).
Changing a field modifier from a static final to a non-static final field (equivalent to adding a field).
Adding a new method.
Transparent changes can also be handled explicitly by the application (except for removing a key or a key field). This allows an application to override the default behavior. For example an application might chose to set a non-zero default value for an integer field.
Removing a key, or a field in a multi-part key cannot be handled by the application. If a distributed query detects that a key was removed, or it's fields changed, it is ignored. No query results will be returned from a node that does not match the key definition of the node that initiated the distributed query.
Non-transparent changes require the application developer
to explicitly code the behavior that to map from a previous version to
the new version. This mapping is done in an
ObjectMismatchTrigger which is described in the section called “Object mismatch interface”. These are the non-transparent
changes:
Changing a field type. This includes changing a field type
from a primitive to its wrapper class. For example, changing a field
from an int to an Integer type
is a field type change.
Changing inheritance hierarchies.
These class changes are not supported:
Changing a field modifier from non-final to final.
Adding a key.
Adding new fields to an existing key definition.
Changing the type of a key field.
Removing a method.
Changing the signature of a method.
Adding or removing values from an enumeration.
Removing an enumeration referenced in a field, even if the field was removed.
Removing a class referenced in a field, even if the field was removed.
Removing @Managed from an existing
class.
Adding @Managed to an existing
class.