-
Enhancement
-
Resolution: Done
-
Major
-
7.11.0.Final
-
NEW
-
NEW
When a user belongs to many groups, UserGroupCallbackTaskCommand.doCallbackGroupsOperation() could be a bottle-neck because it loops over all groups and calls context.getPersistenceContext().findGroup(groupId).
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L164-L169
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L174-L176
https://github.com/kiegroup/jbpm/blob/master/jbpm-human-task/jbpm-human-task-core/src/main/java/org/jbpm/services/task/commands/UserGroupCallbackTaskCommand.java#L195
Kris wrote:
we could try to implement TaskPersistenceContext.findGroups(..) to be able to pass a large number of ids in one call (and then later check which ones are all in there).
Maciej wrote:
I wouldn’t go for this as it will have rather significant code changes - mainly as right now code does not considerer multiple groups. In addition the use of IN ins SQL has usually limitations on some dbs and thus can become problematic. Instead I would recommend to configure cache for users and groups - that in general makes a lot of sense so with that we avoid db roundtrip for every check and we just check the cache which should dramatically improve performance in this use case
- is incorporated by
-
-
- Closed
-
