Setting a custom IdGenerator

[marcus1]

Activiti allows the user to configure a custom IdGenerator in ProcessEngineConfigurationImpl. This is useful for me since I want to use the adapted DbIdGenerator from http://jira.codehaus.org/browse/ACT-789. As I understand it these changes have not been applied to the Trunk since Tom felt it needed more testing in a production environment, which has not happened yet.

So I thought, I’ll just copy the patched code to my own DbBlockIdGenerator and configure the engine to use it instead of the default. However, this does not work.

The problem is that the BlockIdGenerator needs a CommandExecutor. This executor is set on the default IdGenerator the following code in ProcessEngineConfigurationImpl:

protected void initIdGenerator() {
   if (idGenerator==null) {
       DbIdGenerator dbIdGenerator = new DbIdGenerator();
       dbIdGenerator.setIdBlockSize(idBlockSize);
       dbIdGenerator.setCommandExecutor(commandExecutorTxRequiresNew);
       idGenerator = dbIdGenerator;
   }
}‍‍‍‍‍‍‍‍

Obviously this will not work if I want to supply my own IdGenerator. Therefore I made some changes and created a patch.

- I added the interface CommandExecutorAware with the sole method setCommandExecutor. I could have simply added the method to IdGenerator, but that would not be backwards compatible (since people may already have made their own implementation of the interface). I’m sure you will feel free to change this if you feel it is more appropriate

- initIdGenerator in ProcessEngineConfigurationImpl now checks for this interface:

if (idGenerator==null) {
    DbIdGenerator dbIdGenerator = new DbIdGenerator();
    dbIdGenerator.setIdBlockSize(idBlockSize);
    idGenerator = dbIdGenerator;
}
if (idGenerator instanceof CommandExecutorAware) {
    ((CommandExecutorAware) idGenerator).setCommandExecutor(commandExecutorTxRequiresNew);
}‍‍‍‍‍‍‍‍

- I added the DbBlockIdGenerator (which is the DbIdGenerator with the changes from ACT-789).

- The default DbIdGenerator and the new DbBlockIdGenerator now implement CommandExecutorAware.

See http://jira.codehaus.org/browse/ACT-902 for the patch.

[jbarrez]

Afaik, the custom id generator was added to trunk, just not enabled by default.

[marcus1]

I only see two implementations of IdGenerator in Trunk: the default DbIdGenerator and StrongUuidGenerator. StrongUuidGenerator does not need a CommandExecutor.

[ronald_van_kuij]

The second one is the 'new' one…

[marcus1]

I realize that StrongUuidGenerator is newer than DbIdGenerator

We experienced the same concurrency issues as described in this thread: http://forums.activiti.org/en/viewtopic.php?f=6&t=1521

The patch posted by Tom Baeyens in that thread (last post) seems to have fixed this issue for us. However, to be able to configure it (or any other custom IdGenerator which needs a CommandExecutor for i.e. database access), the changes I described are needed (AFAIK).

[ronald_van_kuij]

wasn't the concurrency issue caused by using a db id  generator that  needed db access? So wouldn't introducing a new/custom db id generator that requires this as wel have the same issues? Unless a separate connection is used for this… But then that is needed and not the command executor. Or do I mis something?

[marcus1]

As I understand it the db connection was part of the problem, but that seems to have been solved in the adapted DbIdGenerator.

The generator uses a commandExecutorTxRequiresNew, and thus a separate connection (AFAIK):

if (idGenerator instanceof CommandExecutorAware) {
    ((CommandExecutorAware) idGenerator).setCommandExecutor(commandExecutorTxRequiresNew);
}

[ronald_van_kuij]

Sorry, I meant separate connection pool… The issue was that if all connections are busy doing functional db stuff, there is no connection anymore to retrieve a new id. But I could be wrong that that is solved by the change. If so, the need for the uuid db generator  was superfluous.

[marcus1]

Hmm… I'm now wondering why I haven't simply been using the StrongUuidGenerator… It seems to work fine after some quick tests.