Activiti

Reduce number of task / event subscription queries when execution is removed

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 5.10
  • Component/s: Engine
  • Labels:
    None
  • Number of attachments :
    0

Description

When an ExecutionEntity is deleted, we check whether there are any TaskEntities/EventSubscriptions/Jobs associated with this execution. if so, we remove them.

This leads to an increasingly large number of queries, which is most cases are pointless.

AT:

  • at most one query is performed for entities (Jobs/Tasks/EventSubscriptions...) associated with an execution within a single command

------------

Idea (back from discussion with Tom): the parser could set properites like "isTaskUsed" or "isEventSubscriptionUsed" on the process definition / scope activity.

Based on such properties we should be able to reduce the number of queries.

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. ACT-1134 Reduce number of compensate event subscription queries when a subprocess is completed

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel Meyer (camunda) added a comment - - edited

We should also cache Tasks and Jobs as a transient field (not persisted to DB) in the execution for the current command.

That same strategy is currently used for Process Variables and Compensate Event Subscriptions. The contract is that if you create / remove tasks or jobs, you also have to remove them from this transient list attached to the execution.

This will make sure that we only query at most once per command. As a side effect we obtain that if the process intance finishes in one single transaction, we do not have to perform any query at all.

This will a) greately improve performance and b) solve a couple of bugs where a timer is created in the same command in which it is removed (we currently leak a JobEntity in that situation)

Show
Daniel Meyer (camunda) added a comment - - edited We should also cache Tasks and Jobs as a transient field (not persisted to DB) in the execution for the current command. That same strategy is currently used for Process Variables and Compensate Event Subscriptions. The contract is that if you create / remove tasks or jobs, you also have to remove them from this transient list attached to the execution. This will make sure that we only query at most once per command. As a side effect we obtain that if the process intance finishes in one single transaction, we do not have to perform any query at all. This will a) greately improve performance and b) solve a couple of bugs where a timer is created in the same command in which it is removed (we currently leak a JobEntity in that situation)
Hide
Permalink
Daniel Meyer (camunda) added a comment -

As a second step we should look into the "query at most once" part: identify situations where we do not have to query at all.

Show
Daniel Meyer (camunda) added a comment - As a second step we should look into the "query at most once" part: identify situations where we do not have to query at all.
Hide
Permalink
Joram Barrez added a comment -

+1 on the transient caching. We came to the same conclusion this afternoon.
Of course, as you indicate, this will mostly benefit single transaction processes.

Regarding the 2nd step, there are processes that can be optimized by setting properties on the processdefinition: ie no timers used, no async, etc.
However, that is only a small fraction of the processes... (as you indicated in the original post above).

Show
Joram Barrez added a comment - +1 on the transient caching. We came to the same conclusion this afternoon. Of course, as you indicate, this will mostly benefit single transaction processes. Regarding the 2nd step, there are processes that can be optimized by setting properties on the processdefinition: ie no timers used, no async, etc. However, that is only a small fraction of the processes... (as you indicated in the original post above).
Hide
Permalink
Daniel Meyer (camunda) added a comment -

http://fisheye.codehaus.org/changelog/activiti/?cs=3466

introduces the transient caching

Show
Daniel Meyer (camunda) added a comment - http://fisheye.codehaus.org/changelog/activiti/?cs=3466 introduces the transient caching

People

  • Assignee:
    Daniel Meyer (camunda)
    Reporter:
    Daniel Meyer (camunda)
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: