Oracle vs Apache

So for a while now, Apache has been trying to get access to the Java TCK so that Harmony can be certified. Oracle's not an open source kind of company, so they're not playing ball.

Here's the Oracle official response to Apache, who have been playing hardball to try to get access to the TCK. It totally dodges the issue.

Not only that, but this chickenshit Oracle cog has disabled commenting for this post, because the overwhelming negative reaction would look awful:

http://blogs.oracle.com/henrik/2010/11/moving_java_forward_open_response_from_oracle_to_apache.html

Oracle sucks. Time to start moving my software away from Java?

Maintaining L2 Cached Collections After Cascade Remove

Hibernate's L2 collection caching provides a major performance boost to our application. It's requires an odd mindset from the developer user however - it does some things automatically, but the developer is left with a few critical responsibilities. If you just configure a collections cache but fail to maintain the collection cache properly in your code you can expect problems.

This is very error prone - the developer needs to understand a great deal about how Hibernate's collections caches work 'under the covers' to get everything working just perfectly.

The simple example is removing (deleting) an entity that is a member of a parent's collection. Lets assume I have entities Child and Parent. Parent has a cached collection called 'children'. If I simply do:

childDAO.delete(aChildEntity);

I'm now in bad shape. The parent cached collection still thinks it contains the child that has been removed. Simple enough; the developer is responsible for maintaining the collection (I know I know this code is for illustration only):

aChildEntity.getParent().getChildren().remove(aChildEntity); childDAO.delete(aChildEntity);

Problem solved right? Now lets make the scenario more complex. I have another entity that also cascades delete to children, so it's happening implicitly. Maybe I have 5 or 10 places where this happens. I'm quickly going to have to write a lot of fragile code to make sure this works right.

Instead, what I've done is to use a @PreRemove method on Child to evict the parent collection from the cache. This should be far less fragile. No matter what new and creative ways I come up with of deleting children, the cache should stay clean:

sessionFactory.getCache().evictCollection(com.mycompany.entity.Parent.class.getName() + ".children", deletedEntityId);

Infinispan as Hibernate L2 Cache

We're now using Infinispan as a Hibernate L2 cache. There was only one obstacle: locking of our persistent entities.

Formerly we were using EHCache in a single-server configuration only. We switched to Atomikos + Infinispan and got the app working again. So far so good.

Then I ran some load tests. Uh - oh, exceptions all over the place, mostly Infinispan TimeoutExceptions. I'm using the same lock timeout as in the old EHCache version of the system.

In the end this boiled down to long running processing that was in fact causing lock timeouts. This didn't happen in EHCache possibly because it only supports CacheConcurrencyStrategy.READ_WRITE? I'm not sure; we never pinned down exactly why this arose only after switching to Infinispan.

The app is running very well after sorting through this issue. We've completed load testing and in a single server scenario we get just about exactly the same performance we saw with EHCache.

I wanted to use the Infinispan CacheManager for some app-specific (non-hibernate) caching as well, so I wrote a SpringInfinispanRegionFactory that let me spring-create the CacheManager and wire it to both Hibernate and to my other classes.

The only remaining problem is that we needed a JTA implementation. We went with Atomikos and we aren't happy with it. Bitronix looks good, but doesn't support Infinispan, not even using the last-resource gambit. Jotm is probably OK but the XAPool connection pool that it supports is widely agreed to be awful. Any brilliant suggestions?

Hibernate Lazy OneToOne Associations

Damn, this was harder than it needed to be. I have a bidirectional one-to-one association between two objects. I want the 'owner' object (the one without mappedBy=...) to be able to lazily load the 'owned' object.

 @OneToOne(optional=false, fetch=FetchType.LAZY, cascade={CascadeType.PERSIST,CascadeType.REMOVE})
 @LazyToOne(LazyToOneOption.PROXY)
 @JoinColumn(name = "partyAttentionId")
 ChildObject childObject;

This doesn't work. Supposedly from all the forum posts I read the 'key' would be to get that optional=false in there. No joy, I'm profiling in JProfiler and it's still eagerly loading this property.

Either LazyToOneOption.PROXY isn't intended to work for OneToOne associations (I couldn't find documentary evidence of this) or it's a bug.

The only alternative is to use LazyToOneOption.NO_PROXY and run bytecode enhancement during the build as described here: http://tricksdev.blogspot.com/2009/03/hibernate-bytecode-instrumentation.html

Infinispan Went GA

Infinispan just went GA. Hibernate 3.5 is at a CR. It's getting to be time to try clustering our app using Infinispan and their cache provider for Hibernate.

We have a few machines in the QA lab just waiting for this. I hope our gb switch is fast enough to run an Infinispan cluster. Our app hauls a lot of content, and I noticed that they used Inifiband interconnects (way faster than any ethernet, widely used in high-performance computing) in their benchmarks.

If anyone has already tried Infinispan with Hibernate let me know how it went for you.

Upgrading To Spring and SpringSecurity 3.0

Tonight I upgraded our enterprise Java app to both Spring 3.0 and Spring Security 3.0.


Spring 3.0

Upgrading to Spring 3.0 was easy. It works with spring-*-2.5 XML schemas, so I didn't have to change any of my beans files. The only hitch is that we use Jersey and the jersey-spring module.

We build with maven, and this module's pom has versioned dependencies on Spring 2.5.x, so a bunch of <exclusions> were needed.

Spring Security 3.0

Spring Security was much harder to upgrade from 2.0.4 to 3.0.2. The module structures have changed, so it was a bit of trial and error to find the minimal set of spring-security modules that met our app requirements.

The trouble wasn't over once I had a clean build. Lots of the classes have changed packages, so a number of the beans in our spring security XML file needed to be fixed.

Our old Spring Security config had some quirks. It used the security namespace configuration to create the primary beans (it created them all with an underscore ID, like _formLoginFilter) then created two different filter chains using normal bean definitions.

This doesn't work in SS3. No choice but to manually set up all the bean definitions for all the components of SS. This might be good (lots of flexibility, I learned a ton about SS) but it took hours to get it just right.

The app is running smoothly now, using all the latest Spring goodness. Hope this helps someone!