When a New Model Definition Is Uploaded
When the model definition is uploaded to the license server, feature counts are placed into partitions. Counts are allocated to partitions in the order that is specified in the model definition, starting with the topmost partition.
The following rules apply when allocating feature counts of the same name, but with different versions and expiry dates:
| 1. | Features that match the version specified in the model definition are allocated first. Features with longer expiry dates are allocated before features with a shorter expiry date. |
| 2. | If no features are available that match the version specified in the model definition, features of the next higher version are allocated. Features with longer expiry dates are allocated before features with a shorter expiry date. (Features of a lower version are not allocated.) |
Features holding a start date in the future will not be allocated to named partitions but will remain in the default partition. A feature with a future start date will stay in the default partition even beyond its start date until the model definition is reapplied to the license server.
When the available number of counts has been distributed, any partition for which insufficient counts are available will remain empty or will only be partially filled.
When the model definition on the license server changes, any counts that are currently in use by clients are recorded as used against the partition the counts originate from. If a partition is deleted, it stays active until all used counts have been returned to it. Only after that is the partition removed. This enables the license administrator to maintain an overview of all used feature counts.
Optimization Logic For Model Definition Changes
When the model definition changes, any partitions that are already fully satisfied are skipped when feature counts are placed into partitions. As a result, it is possible that existing features in fully satisfied partitions are not replaced with newly available features that have a longer expiry date. Instead, these newly available features are placed into lower-ranked named partitions (provided that these are not fully satisfied) or the default partition.
To ensure that higher-ranking partitions receive features with longer expiry dates, it is recommended that you delete and re-upload the model definition. This forces a redistribution of feature counts across all partitions, regardless of the current allocation of feature counts.