Replace Play @Transactional with something better 10

Posted by Jens Jäger on November 30, 2013

One of the jpa issues I found in play 2 is the behaviour of the transaction handling.

The default play @Transactional does some kind of magic commit.

Lets have a look at the following controller action.

The problem is the variable task.name is changed in the hibernate persistence context and the change is saved on transaction commit. Of course you can use @Transactional(readOnly = true). But it’s easy to get this wrong.

Of course using readonly = true is not possible on actions they might only update a model under some conditions. In this case you might just confuse a = with == and you could have a nasty data changing bug in your application.

A much better approach would be: Only commit a transaction when an explicit save, update or delete is called from your model. The best way to realize this is a needsCommit thread local variable. The variable will be set to false by the transaction wrapper and to true inside the model methods.

The annotation an the call would look like the original play solutions:

The implementation of the withTx method looks like this:

In your model you need to set the commit variable to true like this:

Now you have a much more solid solution for your transactional handling. That only commits when you call a save in your model.

You find the code in the play4jpa project on github.

JPA configuration for play framework 2

Posted by Jens Jäger on November 19, 2013

In my current play project we decided to use hibernate as JPA implementation.

Here is the configuration we use:

Dependencies in project/Build.scala

Database configuration in conf/application.conf

Persistence unit in conf/META-INF/persistence.xml

Play Framework 2: Ebean vs. JPA 5

Posted by Jens Jäger on November 17, 2013

Everytime you start a new project, you should carefully think about the libraries and dependencies you going to use for your project. This prevents you from building on libraries which will be deprecated in the near future.

In Play Framework 2.3 Ebean will be replaced with JPA. Here is a discussion in the forum about the topic.

The switch is also mentioned in the play roadmap and on Github.

Ebean looks really nice and has some nice features, but when you read some discussions it looks like ebean is mostly unsupported by the original developers, and has some nasty bugs.

JPA implementations like hibernate have bugs as well. But in the end even the nasty ones like HHH-2763, finally get fixed. JPA knowledge is also widely spread in the Java world. If you run into a problem, the chance to get help on stackoverflow or by a coworker is much higher.

For me this means, the big client Play Framework 2 project starting these days, will be based on JPA not Ebean.

The only problem with this approach is that the JPA implementation in play 2 is kind of basic. So we have some work in front of us to make jpa for play more like the ebean implementation or the jpa implementation in play 1.

In the future I will share some of the problems we run into and the solutions we find.

Play Framework 2.2 in IntelliJ, errors in controllers everywhere 8

Posted by Jens Jäger on September 24, 2013

Today I updated an application to Play Framework 2.2. After the creation of the IntelliJ config with “play idea”, I got errors in every reverse route and content call. Here are some examples how the errors locked like:

reverse_routing_error

content_error

After fiddling around a bit I found out that the routes_routing.scala and the routes_reverseRouting.scala had errors to. Hmm this is weird. A look in the module setting (Click on the project folder -> Open Module Settings) provided me this:

module_settings_error

As you can see the folder target/scala-2.10/…/main is not a source folder. Only the underlying controllers and views folder. To fix the errors in the controllers just add “main” to the source folders and remove “controllers” and “views”.

Here is a screenshot how the fixed configurations should look like:

module_settings_fixed

Now the controllers should be fine. Happy coding!

Zero Inbox!

Posted by Jens Jäger on July 20, 2013

I can’t remember when my inbox was empty the last time. It must been years ago.

This means no open support requests. No todos which are not in the project management system. No appointments not scheduled in my calendar. No open ends to catch up. Awesome feeling!

Hopefully I will see this screen more often in the future:

zero_inbox