During my mod_rewrite adventures, I discovered an interesting presentation by Rich Bowen from last year's ApacheCon. It's titled "20 Things You Didn't Know You Could Do With Apache" and you can download the PDF. While writing this post, I found a couple of other interesting presentations that Rich wrote: Introduction to mod_rewrite and Apache 2.2 Rocks! Good stuff Rich - thanks for sharing.
Hibernate has a number of options for configuring its second level cache. For more information on configuring this, you might want to read John Ferguson Smart's article titled Speed Up Your Hibernate Applications with Second-Level Caching.
Up until today, I thought EhCache was the default cache provider, but apparently not anymore. From Hibernate's documentation:
Note that versions prior to 3.2 defaulted to use EhCache as the default cache provider; that is no longer the case as of 3.2.
So what's the default now? It can't be Hashtable since that's not for production use. I doubt it's OSCache since OSCache can't even get its patches into Hibernate. Looking through the release notes, I found out it's NoCacheProvider - seemingly because of an issue with EhCache:
Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache. Instead, default to NoCacheProvider.
That's reasonable I guess. EhCache added support for distributed caching in 1.2. It's a shame they didn't maintain backwards compatibility or they'd still be the default caching provider. Regardless, it doesn't matter who the default caching provider is because it's very easy to change it. Here's how it's configured on one of my projects:
<bean id="sessionFactory"
class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="configLocation" value="classpath:hibernate.cfg.xml"/>
<property name="hibernateProperties">
<value>
hibernate.dialect=${hibernate.dialect}
hibernate.query.substitutions=true 'Y', false 'N'
hibernate.cache.use_second_level_cache=true
hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider
</value>
</property>
</bean>
Of course, you can also configure it directly in hibernate.cfg.xml or a hibernate.properties file.
This leads me to the reason for this post:
What is the best 2nd level (clustered) cache to use for Hibernate?
I'm sure some folks will say Coherence, so let's narrow the question to what's the best open source option?
I've used OSCache in the past. It worked well, but it was kind of annoying that I had to patch Hibernate to make it work. The Hibernate folks say it's OSCache's fault, the OSCache guys say it's Hibernate's fault - so this issue will likely never get resolved. So what about EhCache? I don't know, I've only used it in a single JVM environment and haven't tried it in a clustered environment. Is there anyone using Hibernate + EhCache in production that can verify its effectiveness?
Of the options listed in Hibernate's documentation, the only other options seem to be JBoss TreeCache and SwarmCache. You can quickly eliminate SwarmCache since it never made it past 1.0 RC2 in October of 2003.
That leaves JBoss TreeCache, EhCache and OSCache as choices for a clusterable 2nd-level cache. OSCache is an invalidating cache, which definitely works - but might not work as you expect it to. JBoss Cache only seems to allow a replicated cache which also works. EhCache seems to support both. I don't know if invalidating or replicating is better, but I imagine replicating can get quite chatty if you're dealing with large amounts of data.
But wait - is there another open source option? According to Terracotta's CTO, Terracotta is much faster than JBoss Cache. However, if you read about it on DZone, you'll see that JBoss Cache has no "official" benchmarks.
So what's a developer to do? My current client likes OSCache, but I'm leaning towards EhCache. Which would you recommend?
Of course, if Coherence is only $1K per CPU, maybe that's the obvious choice? Unfortunately, I couldn't find their pricing using Google.
I'm just now starting to create my Comparing Java Web Frameworks presentation for ApacheCon Europe. According to Dave, I'm way late on submitting my presentation. However, I haven't received any late notifications from ApacheCon's organizing committee, so I don't feel too bad.
I think it's interesting how most conferences don't spend much time organizing from a speaker's perspective. The Colorado Software Summit and NFJS are two exceptions. As a speaker, you always know exactly what's going on, what the deadlines are and where you're supposed to be when. With ApacheCon, I feel like I'm in the dark on almost everything - including if I have a hotel room or not. I guess that's the difference between a volunteer organization and conferences where the organizers make money.
Luckily, I've done this presentation quite a few times in the past, so it's mostly an update rather than a rewrite. The biggest changes: dropping Struts 1 and adding Stripes and Wicket. Of course, I could keep Struts 1 since it's not much additional work, but since I only have 50 minutes for the talk (10 minutes for QA), it makes sense to drop it. And yes, I know many of you'd like to see Grails, Seam, GWT, RIFE and Click added to this presentation - but no one wants to sit through a presentation on 11 web frameworks in 45 minutes.
Here's the abstract for the session:
One of the most difficult things to do (in Java web development)
today is pick which web framework to use when development an
application. The Apache Software foundation hosts most of the
popular Java web frameworks: Struts, MyFaces, Tapestry and
Wicket. This session will compare these different web
frameworks, as well as Spring MVC and Stripes. It will briefly
explain how each works and the strengths and weaknesses of each.
Tips, tricks and gotcha's will be plentiful. Lastly, it will
provide attendees with a sample application that utilizes all 6
frameworks, so they can compare line-by-line how the frameworks
are different. This sample application will include the
following features: sortable/pageable list, client and
server-side validation, success and error messages as well as
some Ajax functionality. The frameworks will be rated on how
easy they make it to implement these features.
Without further ado, here's my proposed outline:
- Introductions (5 minutes)
- Pros and Cons (15 minutes, ~2 minutes for each)
- Sweetspots (10 minutes)
- Smackdown - evaluation criteria includes (15 minutes)
- Ajax support
- Bookmark-ability
- Validation (including client-side)
- Testability (esp. out-of-container)
- Post and redirect
- Internationalization
- Page decoration
- Community and Support
- Tools
- Marketability of skills (can it help you get a job)
- Job count (is there a demand for skills on Dice)
- Conclusion (5 minutes)
- Q and A (10 minutes)
During the Pros and Cons, I won't be showing any code like I usually do - there's just not enough time. I'm also adding in a discussion on these frameworks' sweetspots. The Pros and Cons section is largely my opinion, and I think it's important to hear the framework authors' opinions as well.
In evaluation criteria, I'm dropping List screens and Spring Integration. All these frameworks have good Spring support and most support some sort of page-able/sortable list. I can add either of those back in based on your suggestions.
Any feedback is greatly appreciated.