The Oracle Commerce Platform IdGenerator services use ID spaces that can be shared by multiple IDGenerator components. Within an ID space, all IDs generated by these components are guaranteed to be unique. When an IdGenerator starts up, it initializes one or more IdSpaces for use by applications.
The examples in theUsing IdGenerators section describe ways to create an IdSpace programmatically. An IdSpace can also be configured with an XML file. The location of the XML file is specified by an IdGenerator component’s initialIdSpaces property. For example, the SQLIdGenerator uses:
initialIdSpaces=/atg/dynamo/service/idspaces.xml
Each IdSpace is defined in the XML file with an <id-space/> tag. The <id-space/> tag has the following attributes:
Attribute Name | Description | Default |
|---|---|---|
| A string that uniquely identifies an | none |
| The first ID in the space to reserve. |
|
| How many IDs to reserve at a time. |
|
| A string to prepend to the beginning of all string IDs generated from this | null |
| A string to append to the end of all string IDs generated from this | null |
If you want to define additional IdSpaces, it is best not to modify the XML configuration file at <ATG11dir>/DAS/config/atg/dynamo/service/idspaces.xml. Instead, create your own XML file of the same name in your localconfig directory and let the Oracle Commerce Platform’s XML combination facility combine the files. Note, however, that the idspaces.xml file is read only when the das_id_generator database table is empty. If the das_id_generator table is already populated when you add a new IdSpace to the XML file, your changes are not picked up. As a workaround, manually add the IdSpace with the desired prefix to the das_id_generator table before trying to use that IdSpace.
Important: In general, you should not delete IdSpace rows from the das_id_generator table; doing so can cause ID collisions if an application attempts to use the deleted IdSpace. If you are certain that an IdSpace is never used again, it is safe to delete it.
