Since the ABL engine runs under Hibernate, the two must be connected for the engine to be activated. This page will explain how to do this, and how the connection is established.
What to do
To activate ABL, you need to specify one of ABL's current session context classes in your Hibernate configuration file.
In a traditional hibernate.cfg.xml file, it might look like:
<mapping class="buslogicdemo.data.Customer" />
Turn on the ABL engine
In a JPA environment, you would normally specify something like this in your persistence.xml file:
<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
<!-- Turn on the ABL engine -->
Which class should you use?
ABL provides four different classes to be used as a current session context class, as well as a programmatic way to activate it in unusual cases.
If you currently use one of Hibernate's three implementations of
, you can simply substitute it with one of ABL's:
| If you currently use...|| Use instead:|
Slightly more complex cases
should be used if you are not using one of Hibernate's classes. For instance, Spring has its own current session context class, therefore Spring environments should use ABL's
, you must also specify (in the ABLConfig.properties file) which class would normally be used. For instance, if you use Spring, you must have the following line in ABLConfig.properties:
currentSessionContextClass = org.springframework.orm.hibernate3.SpringSessionContext
These four classes should normally take care of all cases. If, however, you are doing something unusual, and for some reason cannot use them, you can also activate the ABL engine programmatically. This obviously must be done before any transaction is started. It is done with a simple call:
The factory parameter must be an instance of Hibernate's SessionFactory. Note that this can be invoked multiple times for the same factory without any adverse effect (other than a few wasted CPU cycles).
Also note that this must be invoked for every Hibernate session factory.
How does it work?
This section explains the internals of ABL's registration with Hibernate, and can be safely skipped, unless you're curious to know how things work.
When one of ABL's current session context classes gets registered with Hibernate, it actually simply invokes
. This in turn will register three event listeners with the session factory, one for delete events, one for post insert events, and one for post update events. This allows the ABL engine to record all relevant activity within a transaction.
As the event listeners get invoked by Hibernate, they will trigger the registration of special action queue processes with the Hibernate session, which will be invoked by Hibernate at commit time. That's when all the business logic will be executed, based on the information collected by the three event listeners.