JPA: Ensuring versioning of entities when using Query.executeUpdate

Thu, 28 Jul 2011 21:16:15 +0100

The persistence layer for our code at The Law Wizard makes use of optimistic locking to determine if an entity has changed during the period where a user has been working on it. This helps to ensure that the view the user sees is always consistent with what is in the database.

One problem I came across is how to update multiple versioned entities in a single query whilst ensuring the benefits of optimistic locking are maintained. It turns out the answer is extremely simple, yet it took me while to find it. I thought I would share in case others have the same problem.

First off I’m assuming you’re using Hibernate as your persistence provider.

Imagine you have an entity such as this:


public class MyEntity 
{
       @ManyToOne(fetch=FetchType.Lazy, optional=true)
       private OtherEntity otherEntity;

       @SuppressWarnings("unused")
       @Version
       private long version;

       public OtherEntity getOtherEntity()
       {
               return otherEntity;
       }

       public void setOtherEntity(OtherEntity otherEntity)
       {
               this.otherEntity = otherEntity;
       }
}

The relationship between MyEntity and OtherEntity is uni-directional, i.e. OtherEntity doesn’t know about the MyEntitys that have a reference to it.

Elsewhere in your application it is possible to delete OtherEntity. If this happens, you would like all MyEntitys with a reference to the OtherEntity being deleted, to have their reference set to null. However you will note that MyEntity is versioned for optimistic locking purposes. If the reference to OtherEntity is set to null, you want the version of MyEntity to be incremented.

A horrible way to do this is to load all MyEntity into the PersistenceContext where the OtherEntity is the one that is being deleted, set the reference to null and then persist them back into the database. For example:



for(MyEntity m : em.createQuery("select m from MyEntity m where m.otherEntity=:otherEntity").setParameter("otherEntity",otherEntity).getResultList())
{
     m.setOtherEntity(null);
}

This ensures that versioning works, but depending on the number of MyEntity referencing OtherEntity, you’ve potentially got a lot of database traffic.

Another way to do this would be to use a query to update all OtherEntitys such as the following:

em.createQuery("update MyEntity m set m.otherEntity=null where m.otherEntity=:otherEntity).setParameter("otherEntity", otherEntity).executeUpdate();

That works, but with one major problem. The version of all MyEntity affected by the query is not updated. I was considering writing my own query to update the versions of all MyEntity when I found this little nugget buried deep in the Hibernate documentation:

In keeping with the EJB3 specification, HQL UPDATE statements, by default, do not effect the version or the timestamp property values for the affected entities. However, you can force Hibernate to reset the version or timestamp property values through the use of a versioned update.

So what does that mean? Well simply re-write the above query to the following:

em.createQuery("update versioned MyEntity m set m.otherEntity=null where m.otherEntity=:otherEntity).setParameter("otherEntity", otherEntity).executeUpdate();

The versions of any affected entities are incremented ensuring that your optimistic locking strategy will work without a hitch.

An elegy for the technical book

Sat, 12 Feb 2011 11:29:15 +0000

I’ve been doing a lot of technical investigation over the last few months as part of our plans for The Law Wizard. Part of that means that I’ve been doing a fair bit of technical reading whilst playing around with lots of new technology.

Brain..not..working

For some reason I really struggle to start with a technology when reading a computer screen. My brain seems to shut down and refuse to do anything, so I often resort to printing stuff off and then reading it.

Printing stuff off works OK, but it often means you have to chase around, finding the articles or pages that interest you. Sometimes you just want everything in once place. Sometimes there is nothing better than getting your hands on a printed manual that really starts to explain the technology to you. My tiny brain can then relax and the information that I need starts to seep in. I’m sure I’m not alone here.

However I’m finding an increasing problem with technical books these days is that as soon as they are printed and in your hand, they’re out of date. The technology has moved on, and that nifty new feature you wanted to use doesn’t even appear in the book. I’m not the only one who has noticed that problem either

Goodbye my old friend?

With Messrs iPad and Kindle on the scene, it is more and more likely that technical books will be delivered in ‘e-book’ format. This will also mean that as and when new features are added, the book will be updated and pushed to our ‘e-reader’ devices automatically. It will be great, knowing that your manual will never be out-of-date.

But on the other hand I can feel my brain already starting to revolt. “You can’t learn when reading from a screen”, it taunts. It has me rushing to Amazon to check the availability date on the second edition of the technical book instead.

Technology brings change to all areas, and technical books are not immune. I’m looking forward to more up-to-date documentation, and I’ll convince my brain that reading from a screen isn’t that hard and it’s just being lazy.

But deep down I also yearn for a updated print copy of the technical book in my hands. There is something rewarding about thumbing through the pages and learning the intricacies of the technology. I hope I’m not alone in feeling that way.

I'm Rob Blake

JPA: Ensuring versioning of entities when using Query.executeUpdate

An elegy for the technical book