activiti uses DBIdGenerator default, when the id block used up, it will request for another block from db, and increase its
current id status, but I am wondering when will the operation of writing id back to db be performed,
if in the same transaction with other operation like update history identity_link, history_task_instance, what will occur when exception arisen? the id in DbIdGenerator wont rollback, and the new id wont commit to db, so next time it request for new block will result in using the old ids?
> In some (very) high concurrency load cases, the default id generator may cause exceptions due to not being able to fetch new id blocks quickly enough. > In (very) limited use cases this can cause problems when there is a real high load.
And, you can use the alternative(the org.activiti.engine.impl.persistence.StrongUuidGenerator)
> which generates a unique UUID locally and uses that as identifier for all entities. Since the UUID is generated without the need for database access, it copes better with very high concurrency use cases.
Or, you can use your original id generator by implementing interface IdGenerator and setting processEngineConfiguration.