redredred

Optimistic locking in JPA relies on a version field which can be a number or a date of some type. Using date objects can be problematic if they are not detailed enough. For example a date which does not persist at least milliseconds is likely not to be accurate enough to do versioning. I generally use a Long since it is going to survive a very long time indeed, even in a high transaction system. The version filed is identified using the @Version annotation and when an object containing a version field is updated JPA will read up the version number in the database before attempting to do the update and if the version numbers do not match then it will throw an OptimisticLockException. It is a good practice to make the version field private and not to provide getters and setters. it is critical that the field not be altered except by the JPA implementation.

Ok, so far so good, we implement this strategy on systems where we have a greater proportion of reads to writes and we would like data to be highly available. Basically a user can always get a read, no matter what, however if they want to do a write we will check that the object they are modifying has not been written to since they read it. Very many web based application use this strategy today and as I described above it is supported out of the box with JPA. Of course there are endless arguments about how you manage the OptimisticLockException, but that is a separate issue.

When your web application is using DTOs or some other representation of the system data which is not your actual domain another level of complexity enters the frame. If the DTOs don’t carry the version field with them and re-present it for the update then the whole optimistic lock strategy is dead in the water. If the web tier represents an object without keeping the version field then when it the user requests to update the domain, JPA must retrieve it again, over-write the fields provided and then perform the update. Of course if someone had changed the data between the user’s read and write, that would be over-written.

So we have established that maintaining the version field into the web tier is critical. We already established that the version field should not be user modifiable so it would be good to make the version field in the DTOs private as well. If you are hand mapping between DTOs and your domain then you will need to use reflection to map this field across. I generally user dozer and it allows you to set is-accessible=”true” in a field description which tells it to access this field directly without using the getter and setter.

When you add Flex and BlazeDS to the picture (and of course that means an ActionScript domain) you add a whole new level of complexity and at this point a real problem arises. Of course BlazeDS will auto-magically transform your Java DTOs into your ActionScript domain and perform all transport in AMF3. Thats peachy, but unfortunately it does not transport private fields without getters or setters. That means that although your version field gets mapped onto the DTO when it arrives on the Flex client, it is gone.

Well that just won’t do, we already established that without the version field we have no locking strategy at all. Currently my only work around is to provide getters and setters on the DTOs. This ensures that they make the trip to the client and back but it risks the client accidentally altering them and inadvertently causing an OptimisticLockException. I’m a little unhappy with this and intend to spend a little bit of time with the BlazeDS source code to see if there is something that can be done to allow private field mapping. If you are interested stay tuned or feel free to post your ideas as comments here.