Histos dot net

HFCD for Flash Builder: Build Your Flex App 2-3x Faster

HFCD is an extension for Flash/Flex Builder that delegates compilation of your Flex application to a special "compiler daemon" which can run locally or on a remote machine.  The goal of the project is simple: faster builds!  HFCD is the brainchild of Clement Wong, the former compiler engineering lead on the Flex SDK team.  Here are a few useful things to understand about HFCD:

• HF installs as a Flex Builder plugin which will delegate compilation to a separate OS-level process running either locally or on a remote machine.
• The compiler daemon process is persistent, meaning it continues to run across multiple builds.  This allows the Java virtual machine to optimize compilation execution each time that a build is run.  The JVM is *very* good at this.
• The Flex Builder plugin watches for file modifications and immediately pushes these changes to the compiler daemon process.  The daemon has an internal representation of the project file system and will launch internal incremental builds automatically when files change.

So, how fast is it really?  I benchmarked HFCD on two different machines.  I used the Flex 3.4.1 SDK for compilation and ran clean builds of my application each time.  My test project was a real-world Flex app currently in development consisting of about 15 modules and 350 MXML files and ActionScript classes.

2006 Intel Macbook Pro, Core Duo 2.16 GHz, 2 GB RAM, 7200 RPM HD, Leopard 10.5, 32-bit Java 5

• Stock: 135 seconds average
• HFCD (1st run): 155 seconds
• HFCD (successive): 75 seconds average

Intel Core i7 920 @ 3.2 GHz, HT off, 12 GB RAM, dual 7200 RPM HD's in RAID 0, Vista 64-bit, 32-bit Java 6

• Stock: 65 seconds average
• HFCD (1st run): 52 seconds
• HCFD (successive): 21 seconds average (!!!)

As indicated in the documentation, the performance of HFCD increases dramatically after the first build due to the numerous optimizations in HellFire and the JVM itself.  The Macbook was nearly 2x faster while the Windows box was just over 3x faster.  Very impressive and a real time saver!

I hope to post some new benchmarks soon.  I need to do some more research to get HFCD running on a 64-bit JVM as that isn't supported out of the box.  Also I'd like to configure my Macbook to delegate the compilation to my Windows box, especially to ascertain what kind impact the network topology has on build performance.

Subversive install for Eclipse has finally improved!

About a year ago the Subversive plugin moved into the Eclipse foundation and became the "official" SVN provider plugin for the platform. Unfortunately due to a licensing issue popular SVN connectors such as JavaHL and SVNKit cannot be shipped with the Eclipse IDE, so a fully-functional SVN Team Provider can't currently (and may never?) ship with Eclipse. The steps required previous to install and get Subversive working were pretty tedious in the past, so I'm happy to report that recently this experience has been greatly improved! There are now only two very straightforward steps to get Subversive running:

Launch the Eclipse plugin installer dialog and select "Subversive SVN Team Provider."

After installation, restart the workbench.  Then open the "SVN Repository Explorer" perspective.  The following dialog will be displayed automatically:

Choose a SVN connector (I typically use the latest SVNKit), click Finish, restart the workbench one more time and you're ready to go.  Hopefully the licensing issues will be resolved eventually so that Eclipse can ship with the Subversive SVN Team Provider by default but at least in the mean time the installation's been made pretty painless.

New Year, New Blog URL

I've upgraded my TypePad account such that you can now access the blog directly via the proper URL:

http://histos.net/

The old URLs will also continue to work:

http://histos.typepad.com/

http://histos.typepad.com/blog/

Feel free to update your blogrolls, etc accordingly. Thanks and have a Happy New Year!

Mixing and Matching Spring JdbcTemplate and HibernateTemplate

The JdbcTemplate and HibernateTemplate convenience classes from Spring really make working with the respective APIs a breeze. Unfortunately getting both of these classes to work together within a single Transaction is not straightforward. This comes up very frequently in JUnit tests where you want to verify Hibernate is working with the database in the way you expect, either by inserting data and letting Hibernate load it or by checking to see that Hibernate creates the data you expect. The same will hold true in application code where you need to add JDBC code alongside Hibernate code to meet various requirements. The testing scenarios are simple and illustrative so let's explore those.

One common use case is to persist an object with HibernateTemplate and then verify the data was inserted correctly using JdbcTemplate. Usually Hibernate will not flush the data out to the DB until the transaction commits, meaning that the query done by JdbcTemplate won't be able to see the new data. This one isn't hard to work around: just call HibernateTemplate.flush() to execute the SQL on demand so that subsequent calls to JdbcTemplate will see the new data.

The second use case is a lot tricker: let's say you want to create some data with JdbcTemplate and then make sure that calls to HibernateTemplate will see that data. By default this will not work. You can actually insert with JdbcTemplate, make a call to load the data with HibernateTemplate (it won't find it) and then make another call to JdbcTemplate which will show that the data is there. The problem is that since JdbcTemplate is injected with a DataSource it doesn't really have any knowledge of the transactions from HibernateTransactionManager; thus operations from the two templates are isolated from one another.

Fortunately Spring offers a solution in the TransactionAwareDataSourceProxy class. Just like the name imples, this class acts as a wrapper for an existing DataSource so that all collaborators will participate in Spring-managed transactions. Configuration of this class is trivial:

<bean id="dataSource" class="org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy">
    <property name="targetDataSource">
        <bean class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
                ...
        </bean>
    </property>
</bean>   

Note: you may or may not want to define the "real" DataSource as an inner bean that doesn't get registered in the ApplicationContext itself. If you are autowiring your DataSource purely by type, having two different implementations of DataSource will be a problem for you. Workarounds include autowiring using @Qualifier or using @Resource to inject the bean by name.

On Hibernate, Spring, Sessions and Transactions

I was recently working with Spring and Hibernate on a pet project and ran into some issues with Session and Transaction management that proved to be pretty interesting in the end. The following assumes a working knowledge of Hibernate and Spring...

I was in the midst of writing some JUnit 4.x tests using SpringJUnit4ClassRunner and the @TransactionalConfiguration / @Transactional annotations for automatic rollback of @Test methods. I wanted to do some manipulation of the database prior to my tests using a separate method annotated with @Before. What I was reminded of very quickly is that Spring's class runner will not apply a transactional aspect to this method since it's not actually a @Test. This isn't a problem if you are using HibernateTemplate / HibernateCallback, since it ultimately has a reference back to your TransactionManager to handle transactions. But if you want to work with the raw Hibernate APIs it can be problematic.

There are two things to keep in mind: (1) SessionFactory.getCurrentSession() will only work if you have configured the SessionFactory appropriately, and (2) depending on the configuration, you may have to manage Transactions explicitly. The configuration property in question is "hibernate.current_session_context_class" and it is commonly configured one of three different ways:

1. Omitted the property from the configuration

Hibernate will throw an exception on calls to getCurrentSession() complaining that there is no CurrentSessionContext configured.

2. Configured with 'thread'

hibernate.current_session_context_class=thread

Hibernate will bind the Session returned from getCurrentSession() to the current thread and you must manage transactions programmatically. Generally all that's required is to call Session.beginTransaction(). You can also invoke Transaction.commit() or rollback() if you wish.

3. Configured with SpringSessionContext

hibernate.current_session_context_class=org.springframework.orm.hibernate3.SpringSessionContext

Hibernate will assume it is executing inside of a Spring transactional context (i.e. through a Spring transactional aspect) and Spring will now manage your transaction for you. However if you call getCurrentSession() outside of such a context, Hibernate will throw an exception complaining that no Session is bound to the thread.

What does all this mean?

1. Use SpringSessionContext if your operations will be done through classes that are invoked through a Spring-managed transactional context or if you can introduce HibernateTemplate and/or HibernateCallback wherever you need it.
2. Use "thread" if you need to raw with the raw Hibernate Session/Transaction API and remember that you'll need to manage transactions programmatically.