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, provided that both of the following statements are true:
| • | The partition name and requested feature counts have not changed. |
| • | No partitions higher in the model definition have been modified, added or removed. |
If either condition does not hold true, used counts are recorded as used against the default partition. Note that adding or deleting partitions that are listed below a partition with counts in use by clients does not result in its used counts being recorded against the default partition after a model definition change.
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.