Simple Persistence

In a previous post (found here) I started talking about the confusion and issues around persistence and PersistenceContexts in a CDI/EE application. In this post I’d like to go over in detail my current solutions and tools to make all this stuff simpler!

Based on some stuff from Seam and Deltaspike I put together a simple persistence framework which allows you to declaratively mark methods requiring transactions with an annotation (@Transaction). Also there is often confusion over how to get access to an EntityManager and when to use extended persistence contexts etc. To simplify this I wanted to be able to @Inject an EntityManager and just have it work instead of needing to use the @PersistenceContext annotation.

The current state of this project can be found here: https://github.com/cbensemann/SimplePersistence.

First up lets define a producer which creates an EntityManager for us and will allow us to just inject it using the standard @Inject annotation. There’s a bit of discussion around as to whether this is actually a good thing or not and you are essentially doing away with container managed transactions (and the extended persistence context) in doing this but I still feel overall that its easier and cleaner. You can decide for yourself.

Naming Strategy

Personally I’m not a big fan of Hibernates default naming strategy. Tables shouldn’t be created with capitol letters etc. For this reason I normally prefer a slightly adjusted version of their ImprovedNamingStrategy which names tables using lowercase and underscores.

Transaction Management

Next I needed a way to define transaction boundaries now that we’ve abandoned container managed transactions. So I added a @Transaction annotation and an Interceptor.

Hibernate Filters

The final feature of my SimplePersistence is integration with Hibernate Filters. These are essentially a way to automatically add an additional where clause to entity queries. Again taking Seam for inspiration I wanted to be able to define an EL expression to define when the filter is to be enabled and also to allow EL to define the value to used in the filter. Also I want to only have to define the filter once so it needs to be able to be specified on the package level as well as class level.

 

Hibernate Filter Extension

As you can see its a bit of a work in progress with some TODOs and methods not fully finished but it works enough for my current project. Basically all that is happening here is that we are collecting up all the instances of @FilterParameters that are found during startup and creating a value object to hold their values in a map keyed on the filter name. This allows the TransactionInterceptor defined above to enable a filter as needed when creating a transaction.

Defining a Filter

And that’s it. We can now annotate our business methods with @Transaction(filter = “organization_filter”) and have that automatically enabled.

I’m finding that by combining these new “Simple” modules that I’m creating allows me to easily create and extend web apps in a quick and consistent manner.