The id generator can be configured in idspaces.xml for component atg\dynamo\service.
<id-space name="orderId" seed="200" batch-size="100" prefix="PKP"/>
The IDGenerators execute as follows:
1. When the first IdGenerator starts, it performs the following tasks:
3. When each IdGenerator exhausts its supply of reserved IDs, it returns to the ID generator table and reserves another batch of IDs. It does not need to consult with other IdGenerators to guarantee that its reserved IDs are unique.
IdGenerators and IdSpaces
Dynamo IdGenerator services use the concept of ID spaces. IDs generated by an IdGenerator are guaranteed to be unique within a named ID space. This enables you to have distributed IdGenerator components that share an IdSpace, ensuring that two different IdGenerator components do not use the same ID. 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 <idspace/> tag. The <idspace/> tag has the following attributes:
If you want to define additional IdSpaces, it is best not to modify the XML configuration file at <ATG9dir>/DAS/config/atg/dynamo/service/idspaces.xml. Instead, create your own XML file of the same name in your localconfig directory and let Dynamo’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.
<id-space name="orderId" seed="200" batch-size="100" prefix="PKP"/>
The IDGenerators execute as follows:
1. When the first IdGenerator starts, it performs the following tasks:
- Consults the IdSpace.
- Starts with the seed ID and reserves all IDs that start with the seed, up to the batch size, 100.
- Sets the value in the ID generator database table to 101. UPDATE SEED COLUMN
- Consults the ID generator table and finds that the first available ID is 101.
- Reserves all IDs from 101 to 200
- Sets the value in the ID generator database table to 200.UPDATE SEED COLUMN.
3. When each IdGenerator exhausts its supply of reserved IDs, it returns to the ID generator table and reserves another batch of IDs. It does not need to consult with other IdGenerators to guarantee that its reserved IDs are unique.
IdGenerators and IdSpaces
Dynamo IdGenerator services use the concept of ID spaces. IDs generated by an IdGenerator are guaranteed to be unique within a named ID space. This enables you to have distributed IdGenerator components that share an IdSpace, ensuring that two different IdGenerator components do not use the same ID. 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 <idspace/> tag. The <idspace/> tag has the following attributes:
Attribute Name
|
Description
|
Default
|
---|---|---|
name |
A string that uniquely identifies an
IdSpace within an IdGenerator . An IdGenerator can refer to an IdSpace using this name. |
none
|
seed |
The first ID in the space to reserve.
|
1
|
batchsize |
How many IDs to reserve at a time.
|
100000
|
prefix |
A string to prepend to the beginning of all string IDs generated from this
IdSpace . |
null
|
suffix |
A string to append to the end of all string IDs generated from this
IdSpace . |
null
|
If you want to define additional IdSpaces, it is best not to modify the XML configuration file at <ATG9dir>/DAS/config/atg/dynamo/service/idspaces.xml. Instead, create your own XML file of the same name in your localconfig directory and let Dynamo’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.
Are you sure the example you gave is correct? As per the xml definition () the seed is supposed to block from 200-300 on first attempt and then 300-400 on second attempt right?
ReplyDeleteRight. Thats a typing mistake. He meant
ReplyDelete