Drools Abstract Persistence Layer


On the past two months, and under Intalio’s sponsorship, I’ve been working adding a new persistence layer into Drools. The main goal of this is to support Berlkey DB as persistent backend. Added abstractions are on that direction.
The approach for this task was to work on top of the current drools-persistence-jpa module. Is assumed this module is tested enough (through junit or merely day-to-day usage) and this is the one who defines the semantics which drools persistent applications should attach.

Little background on managing persistence

When you use the engine in a regular way, you obtain the ksession through the kbase and it doesn’t know anything about how to persist its state. To provide the ksession with persistence capabilities Drools makes use of the command pattern. That way, instead of creating it directly from the kbase you go through a factory which will return a decorator which will handle how and where the state is persisted. Being a decorator, at this point, will be totally transparent to the user whether or not the state is persisted.

Abstracting persistence

As the name dictates, drools-persistence-jpa module is heavily oriented to JPA usage. Then, what we have made here was to clean up the use of JPA interfaces and move them into this module.

The most used interface by JPA is the EntityManager, this one was abstracted by the PersistenceContext interface which now has specific methods for persisting SessionInfo’s and WorkItemInfo’s.
Internally Drools uses different scopes for dealing with persistenceContext’s, one for the whole application and one for each command. This behaviour has also been abstracted into PersistenceContextManager.

Persistence layer before refactor

Persistence layer before refactor

Persistence layer after refactor

Persistence layer after refactor

Backward compatibility

Other important aspect of this refactor is that maintains backward compatiblity. That means that, for the moment, you shouldn’t notice any difference if you already have your JPA application running. Current way to configure the ksession is still the same but we’ll add some new in the future, which, I wish, will end up being more polish and abstract.


This persistence refactor also applies for jbpm5 which now have a ProcessPersistenceContext and a ProcessPersistenceContextManager.

What’s next

In a comming post I’ll show a reference implementation on the top of a regular HashMap.


2 Responses

  1. […] This post was mentioned on Twitter by diogenesMoreira, PlugTree Labs and Pablo Nussembaum, Diego López León. Diego López León said: Drools Abstract Persistence Layer: http://wp.me/pT9x2-22 […]

  2. […] from the abstraction described in my previous post this is the new hierarchy for persisting drools runtime into a HashMap. Drools abstract storage […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s