jBPM: Runtime Strategy: Choose wisely
Tags: processes
Published: 2020-07-05 04:59:17

---
title: jBPM: Runtime Strategy: Choose wisely
published: true
date: 2020-06-16 17:50:37 UTC
tags: Processes
canonical_url: https://karinavarela.me/2020/06/16/runtime-strategy-choose-wisely/
---

Kie Server can be configured to deal differently with the requests it receives and the objects it stores in memory or in the database. Properly configuring how the engine deals with the objects in memory, ensures a project with fewer resource consumption and avoids unexpected behaviors.

> _Runtime Strategy configuration affects directly how the engine deals with the lifecycle of the Kie Sessions and objects loaded in memory._

You have to choose between four options, for each new project deployment you create:

- Singleton Runtime Strategy                       
- Per Process Runtime Strategy
- Per Request Runtime Strategy
- Per Case

## **Choosing a strategy**

Understand the key concepts of each strategy to guide your decision of when you should use each of them:

**Singleton Runtime Strategy:** If you create and deploy a project, this runtime strategy configuration is used. It’s the default configuration. This strategy uses a single Kie Session. This makes things easier for beginners since every inserted object is available in the same Kie Session. Also, jBPM persists the Kie Session, and it is reused if the server restarts.

Rule execution within processes can be impacted. Consider that: if process instance _A_ inserts person _John_ to be evaluated by business rules. Process instance _B_, inserts _Maria_. Later, when process _C_ fires rules for its own person, _John_ and _Maria_ will **still** be in memory and will be evaluated by process C rules improperly!

When using this configuration, process execution happens within a synchronized `Runtime Engine`: it is thread-safe. Consequently, this characteristic can affect and bring consequences on performance. If you expect a high workload, or if the project use timers or signals in the process definitions, you may want to consider a diﬀerent strategy for your production environment.

**Per Request Strategy:** defines a stateless behavior. The engine will create one Kie Session per request and destroy it at the end. The Kie Session will not be persisted. This is a good choice for high workload environments.

The following situation can occur: Consider two requests executed simultaneously to interact with the same process instance. One of the two requests might lock a database row to update it, and the other request might try to update it as well. This will lead to an `OptimisticLockException`.

This strategy might do the implementation more challenging if your project uses timers events or if the process involves business rule tasks.

**Per Process Instance Strategy:** recommended when your process uses timers and businessrule tasks. The Kie Session is created when the process instance starts, and it dies, when the process instance ends. This is usually adequate for most use cases.

> _Keep in mind: creating Kie Bases is an expensive operation. Creating new Kie Sessions is cheap._

The engine stores the Kie Session in the database, and always use the same Kie Session for the same process instances.

**Per Case:** this strategy should be used if you are using a Case Management project. If you create a new “Case Project”, this strategy is selected by default. The Kie Session will last while the case is still opened (active).

Now, let’s check the possible places to configure Runtime Strategies, and when should each one be used.

### **Choosing where to configure the strategy**

**Container Level** : Affects the deployed kjar. Configuration can be made in kie containers using Business Central via the _Execution Servers_ page.

![](https://karinavarelame.files.wordpress.com/2020/06/screen-shot-2020-06-16-at-14.45.26.png?w=1024)

**Project level** : The configuration will affect only this project. Configuration can be done via Business Central in the XML file or via. Inside the file `src/main/resources/META-INF/kie-deployment-descriptor.xml` the following configuration is present: SINGLETON

![](https://karinavarelame.files.wordpress.com/2020/06/screen-shot-2020-06-16-at-14.45.42.png?w=1024)

**Server level** : No UI Available. A new system property needs to be configured pointing to the new file.

This change will impact all projects from this server. A new `deployment-descriptor.xml` needs to be provided with **all** the tags and components (not only the ones which you want to customize). The system property is `org.kie.deployment.desc.location` and its value must point to a valid accessible file: “`file:/path/to/file/deployment-descriptor.xml`“

**[INFO]** If using the server level configuration, make sure to provide a valid XML file. See more details about the configuration in the official documentation, topic “ **Default deployment descriptor”**  
[https://docs.jboss.org/jbpm/release/latest/jbpm-docs/html\_single/#\_deployment\_descriptors](https://docs.jboss.org/jbpm/release/latest/jbpm-docs/html_single/#_deployment_descriptors)

* * *

Finally, considering that we can configure the runtime strategy in three different places, this is how the precedence works by default: _Container configuration overrides KJar and Server configs._ _KJar configuration overrides Server configs._

* * *

_This blog post is part of the fifth section of the [jBPM Getting started](https://karinavarela.me/jbpm-getting-started/) series_:   
[Techniques to boost a BA Project](https://karinavarela.me/2020/06/15/techniques-to-boost-a-ba-project/)