Information Technology Reference
In-Depth Information
KIE Session Sharing Considerations
Finally, another consideration to have when running on highly concurrent environments is
one further consequence of sharing a KIE session between many process instances. Due to
actions
), it will be able to recover and continue the KIE session execution from another
thread, but only one thread at a time will be able to manage invocations to a KIE session.
This is because they will edit the same tuple in the database (for the
SessionInfo
table)
and internal locks on the database connection configuration will either throw an exception
or lock the tuple in the database. Either way, only one thread will successfully access a KIE
session at a time to avoid data change collisions.
When considering high concurrency environments, we will need to take this situation into
account, as two process instances that share the same KIE Session won't be able to execute
from two different threads at the same time. On a single standalone server, this could be
managed with a synchronized block around a KIE session method invocation; however,
with multiple nodes, this could become a problem that could occur a certain number of
times.
In order to avoid this error, the implementation of the persistence for Drools provides an
OptimisticLockRetryInterceptor
component, that when a concurrent modifica-
tion problem arises, hangs the latest thread and retries the execution milliseconds after-
wards. This usually saves the few cases where this problem could happen if you don't share
the session too much. However, in order to avoid having this situation too often, we will
need to consider partitioning our KIE sessions in a specific way, and try to see whether a
per-process instance runtime manager could fit our needs.
