Spring 3 @Async with Hibernate and Spring Transactions

The other day we ran into a fun little problem while trying to use the Spring 3 @Async annotation. We had the following scenario:

A web service was invoked by a client app to update some things in the database. Based on what was updated several other calls had to be made to the database to update even more data. When all was said and done this process could take upwards of 15 minutes to complete which is pretty bad considering the SLA was 10-30 seconds. The obvious problem here is this class is doing WAY too much, but that is what the user's wanted so that is how things had to be.

The call stack looked something like this
->Call in to web service from client - (a few calls happen within this service besides the call listed below)
--->Web service calls service facade to run calculations - (This method is transactional since it reads and writes to the database, this method is also called twice in the web service.)
------>Service facade calls a DAO object (backed by hibernate) many many times.
<---Return to client after an eternity.


Our solution to this was to make the slow part asynchronous with Spring 3's new, awesome @Async annotation. So we annotated the service facade with the @Async annotation and thought our super
slow process would run in the background. We put some log statements in the beginning and end of the slow process so we could be sure the method was actually executing in it's own thread after the web service
call returned, it blew up big time. After searching on Google for a while I found out that having @Async and @Transactional on the same method can cause issues from time to time. So we created another service
facade to call the old service facade. We annotated the new facade with @Async and left @Transactional on the old facade. This approach got us further but failed on the second call to the service facades.

 You will notice above that the service facade is called two times from within the web service, the first call worked perfectly. The second call would fail with a org.hibernate.exception.GenericJDBCException: Cannot open connection exception when trying to access a member variable attahed to a parameter in the service facade. Once I dug into this I noticed the parameter object being passed to the service facades was actually a hibernate backed domain object which was populated inside the web service. The member
variable we were trying to access within the service facade was actually a collection of objects that was set to be lazy loaded. When this object was passed to the asyncronus service facade it was not fully
populated, just backed by hibernate. That being said when the async service tried to load up that collection of objects backed by hibernate the hibernate session the object was loaded on was killed
when the first thread exited, the web service thread, thus causing hibernate to fail. By moving the loading logic for that object into the ansync method everything started working!

Extracting Movies Times from Google with Mule 3

Hey everyone, this is going to be a multipart series on what it takes to stand up a mule 3 service with the latest features to communicate with CityGrid web services and pull movie times from google and expose them using REST/JSON. To start with I am going to open up all the source code of the mule service then walk through each facet of the system over the next couple weeks. The system, affectionately named UDoin (more on the sweet name later) currently has the following features:

• UDoin takes in a set of latitude and longitude coordinates via a REST/JSON service and retrieves restaurants, bars/clubs, movie times/theaters within a radius of the given location.
• The coordinates are fed to CityGrid along with a few other arguments and this is where the restaurants, bars, and clubs come from. This is done using Mule's new style of multi-casting router the "All" router.
• After results come back from CityGrid movie times for the current location and time are extracted from Google using the open source HtmlParser project and put on the UDoin response.
• UDoin comes complete with JMX to monitor the system health in real time.
• UDoin uses maven for dependency management and packaging to allow for seamless integration with a CI server such as Hudson.

For the next installment I'll go over the initial setup of the mule project within eclipse. In the meantime go and checkout the source code from https://subversion.assembla.com/svn/udoin/udoin-server/

Unit Testing CXF Web Services

Here is a quick little unit test setup to test your CXF service class and your client class. This is nice if you are testing marshaling issues.

@Test
  public void testMyWebService() {
    MyWebServiceImpl endpoint = new MyWebServiceImpl ();
    JaxWsServerFactoryBean svrFactory = new JaxWsServerFactoryBean();
    svrFactory.setServiceClass(MyWebServiceInterface.class);
    svrFactory.setAddress("http://localhost:9000/myService");
    svrFactory.setServiceBean(endpoint);
    svrFactory.create();

    JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
    factory.setServiceClass(MyWebServiceInterface.class);
    factory.setAddress("http://localhost:9000/myService");
    MyWebServiceInterface client = (MyWebServiceInterface) factory.create();

     List details = client.performSomeWebServiceAction("11");
    Assert.assertNotNull(details);
  }

That's it! This will bootstrap an actual JAXWS version of your service within your JVM and hit it with a real CXF client. One thing you have to make sure of, if you are running tests on a CI server be sure to use a port which is not in use on that build box.

Fixing Eclipse JDK Issue

If you have ever had the issue of eclipse complaining it was not running in a jdk here is how to fix it. Open the eclipse.ini file at the root of the eclipse installation. Add this line to the top of the file, change it to point to your jdk...

-vm
C:\Program Files\Java\jdk1.6.0_11\jre\bin\javaw

Restart Eclipse and you are done!

CXF Interface Extending Another Interface

Just a fun little finding for the day. In the newer versions of CXF you cannot have an interface you define as a WebService extend another interface. This tends to throw a SOAP Fault Exception "Unexpected Wrapper Element". The solution for this is to create another service for the interface you are extending or just merge all the methods into one interface.

Spring JDBC Template Tuning

Had a fun little issue the other day with spring's JDBC template. I was querying a fairly large data set, about 65 million records, and realized the job was running slower than molasses going uphill. After debugging the code I found the query was returning very fast, so the database was not the problem. The issue ended up being JDBC template itself, namely the fetch size. If you do not configure the fetch size explicitly the template will use the driver default, which for Oracle is 10, the database I was working with.

The rows returned from my test query was about 53,000, so with a fetch size of 10 this would take  5,300 network trips to retrieve all the data and store it in memory. Before tuning this operation took about 2.5 minutes to run.

One thing to keep in mind when tuning the fetch size is memory consumption. You should be sure you will have enough memory available to store the result set. For my example I set the fetch size to 10,000 as my result sets were always very large. I was also working with a batch job which ran during off-peak hours, so I knew my available memory would be plentiful.


After setting the fetch size the operation took 15 seconds to run, way better than before. Nice!

Sample code:
On a dao class extending JdbcDaoSupport  I stuck this in an overridden initDao() method.
simpleJdbcTemplate.setFetchSize(1000);

Here is another good post about JDBC fetch size: http://webmoli.com/2009/02/01/jdbc-performance-tuning-with-optimal-fetch-size/

Dust off the old blog

Been a couple months since I have added anything to this blog, I was too busy with work. I have a new job now that is structured a little different, I will have some time to add to this every once in a while, here it goes...