Tag Archives: Spring

Integration testing transactions and optimistic locking with Spring and JUnit

Posted on by
12 Replies

I did some badness today.

I wanted an integration test to check to see if my @Transactional method actually did rollback on an optimistic lock failure. It’s a pretty business critical method so I wanted to be sure that the whole @Transactional and @Version annotation voodoo actually works.

The approach I took was to inject, what I called a “slowRepository” into the object with the @Transactional method. The slowRepository is just a mockito mock of the object which “answers” (using “thenAnswer”) to the “findBy…” with some custom code.

The idea is that at some point during the @Transactional method the slowRepository is called and the “answer” code is invoked. In the test, the answer code follows along the lines of:

1. Grab the data it requires from the (not slow) repository (the repository the slowRepository is mocking)
2. Switch back the slowRepository for the not slow repository
3. Invoke the @Transactional method again on a separate thread
4. Sleep for a bit
5. Wake up and return the data from step 1

The @Transactional call on the separate thread completes and commits before slowRepository wakes up. When it does, slowRepository returns stale data and the @Transactional method then fails accordingly.

The problem I encountered was using the setters for my @Autowired dependencies on the bean with the @Transactional method. I needed to use the setters so that I could switch in and out the slowRepository, but couldn’t because Spring AOP proxies are implementations of an interface, not subclasses (by default – yes I realise you can get Spring to proxy the target class using CGLIB). I found this blog post which explains how to get at the target object behind a Spring proxy. I converted it to Scala:

…which is pretty ninja.

So, what the hell happens when you try and save changes to an @Version’d entity when another thread saves it’s changes before you?

Posted on by
5 Replies

Imagine you’re setup with a JPA 2 environment, using Spring Data JPA and Hibernate is your JPA vendor. You have a UserRepository interface which extends JpaRepository and therefore a Spring generated userRepository bean for all your user DAO needs. You also have a User domain object with a field annotated with @Version.

FYI, your find, save, delete etc. methods in your userRepository are automatically @Transactional. Thank you, Spring.

Ok, lets formalise this a bit:

Thread 1 finds User record with ID 1
Thread 2 finds User record with ID 1
Thread 2 changes the email address field
Thread 2 saves the changes to their version of the user object
Thread 1 changes the email address field
Thread 1 saves the changes to their version of the user object

At the point where thread 1 saves changes, it’ll check the version field of the user object and also the version of the user object in the database. They’ll be different, and a HibernateOptimisticLockingFailureException will be thrown.

Note also that the exact same thing happens if either thread 1 or thread 2 had deleted the object. So, all well and good huh? Check this out for sensible:

Thread 1 finds User record with ID 1
Thread 2 finds User record with ID 1
Thread 2 changes the email address field
Thread 2 saves the changes to their version of the user object
Thread 1 changes nothing, but then saves their version of the user object

What happens here? I originally thought thread 1 would throw an optimistic locking exception. Except, it doesn’t – Spring/JPA/whoever is in charge back there is smart enough to know that nothing changed, so it doesn’t save anything, and you end up with thread 2′s changes as you wanted. Clever girl.

Woes with Scala native types, Spring, JPA and FreeMarker

Posted on by
3 Replies

I’m working on a project using Scala, Spring, JPA and FreeMarker (as you probably guessed from the title of the blog post). I love working with Scala because for the most part, it makes my code more succinct and it is really exciting to work with. I mean, there are obviously other reasons but those are two big ones.

What I don’t like is having to convert between Scala and Java equivalents, but sadly it is unavoidable. The scala.collection.JavaConverters and scala.collection.JavaConversions objects make this a lot easier through implicit and explicit conversions but it does make you wonder what the performance hit is…

I mostly choose to ignore that there is a performance hit – performance problems are a happy problem anyway right?…and at the moment the benefits of being able to write code in Scala greatly outweigh any of my worries.

I use Scala types wherever possible in this project i.e. List, BigDecimal etc. but sometimes it’s just not possible. My domain objects have to use Java types because the JPA vendor doesn’t know how to translate the Scala types into SQL column types. The same goes for objects that are going to be passed to FreeMarker. FreeMarker cannot iterate over a Scala list using the <#list scalaList as item> syntax as you normally would since it doesn’t “know” what a Scala List is. As far as FreeMarker is concerned a Scala List is a java.lang.Object (see scala-lang.org/node/71).

My repositories are generated dynamically by Spring. Basically you define an interface and Spring magically generates a class that extends Spring’s JpaRepository and implements your interface. There is no two ways about it, I want this magic, but it means that the “interfaces” (which are coded as traits in Scala) have to return Java lists for findAll or findBy operations – boo.

Overall it isn’t actually that much of a pain, so I don’t know why I’m complaining about it. It is just something that slightly tarnishes the code, but I guess I can live with it. After all I did decide to use a bunch of Java frameworks with my Scala code. Why didn’t I just use Scala frameworks? Well, mostly because I’m pretty mad, but I’m not completely insane. I figured switching from Java to Scala was a big enough brain realignment without changing everything else I’m used to using as well.

Extensions to Spring’s FreeMarker macro’s (spring.ftl)

Posted on by
7 Replies

Spring’s FreeMarker macro’s are pretty useful, but there are a couple of things I need from the showErrors macro that simply aren’t there:

  1. Show errors without a HTML tag around them – if you don’t specify a classOrStyle, the showErrors macro will wrap your error message in a <b> tag. If you do, it’ll wrap it in a <span> (understandably)
  2. Pick the tag that surrounds each message – As explained in the first point, you can see we only get the choice of <b> or <span>. What if I wanted to use an <li>? …use the separator? – no good, because unless I write an <#if> statement to check the number of error messages before I call showErrors I’ll end up with redundant <ul>/<ol> and <li>’s in my markup if there aren’t any errors:
    e.g. <ul><li><@spring.showErrors “</li><li>”/></li></ul>
    Which leads me nicely onto the next point:
  3. Show errors in an ordered/unordered list, automatically detecting zero messages and not outputting markup if this is the case
  4. Show errors for multiple bind paths – Spring’s showErrors only shows errors for the currently bound field. However I’ve found that I’ve needed to show errors for 2 or more fields together. This is particularly true of a DOB field where the day/month and year are separate <select>’s
  5. Finally, show errors for multiple bind paths, in an unordered/ordered list

You can download my Spring extensions here: springx.ftl. Inevitably I’ll find more bits and pieces to add and will update them accordingly.