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.