We, at www.digijava.org, use Hibernate for O/R Mapping and persistence and most of the things went smoothly so far, but we need to deploy our application to a clustered production environment and we have the problem that Hibernate cache does not support cluster.

Gavin, in his interview on TTS and on this forum, mentioned that Hibernate will have that feature in the timeline of version 2.1. Well, Hibernate 2.1 beta4 is out, however. We went through the code and it seems - everything is ready for that piece but the piece is missing itself.

We really need to do some implementation, ASAP. And we would hate to waste resources on some ad-hoc fix. I beleive that. in the true spirit of open-source, it would be much more beneficial for both us and Hibernate community, if we, and whoever else interested - including Hibernate team, unite our effort and deliver the correct solution for the community. I have a team of professional Java programmers with Hibernate experience, standing by to work on it.

We ask, Hibernate team, to guide us, tell us about their thinking of this subject, and whoever else interested and willing - to join the efforts. Let's deliver the proper implementation, faster, please.

For better or worse, we are in the "can't wait more" situatuation. If I don't get any response we will have to go ahead with our own implementation that may not be what you guys were planning, and may be not valuable for the Hibernate in general. I would hate that to happen, that's not open source - that's like working in Microsoft . Net :-) (kiddin')

Thank you and hope to hear from you soon.

P.S. Thanks for all the great work you did with Hibernate. Having used it for several months, by now, we got loving it. Great stuff.

Gavin is not online at the moment. I know that he has been working on this, and we already have a provider for Coherence: http://www.hibernate.org/132.html

Integrating Coherence, SwarmCache, JGroups and all the others is not rocket science, but I think it would require extensive testing. I hope you can wait one or two days until Gavin gets a chance to reply. Meanwhile, have a look at the Coherence provider and the extension points.

Christian, thank you very much. Very useful piece of information.

Yes, we will wait for Gavin. Hope he gets available soon :)

If we are too late, we will, probabely, deploy this application of ours using Tangasole, and continue working with you on an open-source alternative. That would be a pitty tho.

Meanwhile, what do you think about http://swarmcache.sourceforge.net/

Thanks

Jason an John have a patch in JIRA for using SwarmCache.

Gavin,

Following your recommendation, we reviewed SwarmCache + Hibernate pair and did some tests on it. We had couple of minor problems.
1. The original version of SwarmCache had problems shutting down Javagroups communication thread, as well as the Timer cache "garbage collector" thread which is responsible for the removal of the timed-out items from a cache. A destroy() method was added to the caches (currently only LRU and Timer cache implement this method. Others throw java.lang.UnsupportedOperationException) and Hibernate's cache provider for SwarmCache was changed to use this method.
2. SwarmCache was not configuring Timer cache from swarmcache.properties file. It was also fixed

After item 1 was successfully completed, thread shutdown problem disappeared. The only inconvenience remaining is that SessionFactory needs to be explicitly closed (using close() method) to destroy QueryCache, which also uses SwarmCache. This operation finalizes all the threads and lets application be completed successfully.

Overall, the bundle performed much better than JCS, that we were using before. JCS has some real serious issues :) Several to name: 1) Memory leaks 2) Remote Caching not working 3) Clustered deployment support not completely developed. So, it was a very good move, for us, to switch to SwarmCache in Hibernate. Thank you for your guidance.

You can find the fixed bundle at the following address, in case you are interested: http://www.digijava.org/swarmcache.zip

We were, also, glad to find the new QueryCache feature in Hibernate 2.1. This was something long awaited for, by us. We did some tests - works fine. We have a suggestion there, from our practical experience of business needs, though, if you do not mind.

Some modules in our system operate with the objects of a significant size, so the only efficient way to query data is to use the Scalar Queries. We know that Hibernate also supports caching of Scalar Queries but unfortunately, the results, all go to one cache - QueryCache (compared to Hibernate-persisted objects query, where there's separate query for each class). This is a significant problem for us, and we believe, will be for other users too, because - not all the queries are to have the same cache properties like timeout, max number of objects, max cache size etc. Shortly, we believe, more granularity, in Scalar Query caching, is essential for any mid-to-large size application. We would like to add this feature to Hibernate, but were wondering if you have also thought of it, already, and would point us to some particular direction.

Mikheil, from my team, is working on the implementation of the feature. He is almost through it, doing some tests, and we will share the code as soon as we are finished, of course, but I wanted to share our thinking first, so that if you have some feedback, we can incorporate it into the code now. The way we approach the problem is - we introduce the ability of associating any HQL Scalar Query with a named cache. This will give us both better granularity and the ability to "group" some query results together. The implementation is intended to be backwards-compatible to current, single-cache solution in Hibernate, too. What's your take on this?

thank you

Please let John and/or Jason know about this, so that we can get these fixes into Hibernate (which now integrates SwarmCache).



Very interesting. How do you propose to expose this to the user? I can think of a couple of possibilities:

(1) Query.setCacheRegion("foo")
(2) associate table names with cache regions in the metadata

I am inclined to think that (1) is better and it looks like thats what you are going for.....

Gavin,

We finished implementation and test of the modified Scalar Qeuery Cache. The zip archive below contains files, which were modified to divide QueryCache in multiple regions.
http://www.digijava.org/QueryCache.zip

Most of the old code is commented out, not removed, for the easy comparision.
Here is a description of the major changes
1. There were 2 caches in QueryCache.java - query cache itself and timestamp cache. The last one was moved to the separate class, because we didn't divide that cache.
2. cacheRegion property was added to the Query and QueryParameter classes
3. There is a new method, getQueryCache(String cacheRegion) in SessionFactoryImpl. It returns query cache, stored in the internal map or creates new one and puts it there. It also destroys all these caches in the close() method.
4. There are some minor changes, too. For example, default query cache's region name was changed to net.sf.hibernate.cache.QueryCache. This was done as object cache's region name equals to classname and there may be conflict in naming if someone has QueryCache class (without package) in his code.

Your feedbackis highly appreciated

Thank you

The correct way to submit patches is to

* produce a patch using cvs diff
* submit it to JIRA

TIA

I am still experiencing this problem with Hibernate 2.1 and SwarmCache 1.0RC2 (current). Was this fix integrated into Hibernate 2.1?

I'm beginning to wonder if there's some Hibernate shutdown code I need to execute when my application (EJBs under Websphere 5) exits. Is there something I need to do when I app is shutdown? How do people typically do this?

SessionFactory.close()

Gavin,

Thanks!

Now all I need to do is figure out from where I should call that method. I'm looking for a way to know when my EJB Module is being shut down by the application server, and from there I can call SessionFactory.close() to properly shut Hibernate down.

Any ideas?

Deploy fake servlet with "load-on-startup" option and call "factory.close" in "servlet.destroy" method.

Check out the spring framework and specify your session factory as a bean setting destroy-method to "close". Works nicely :-)

I usually write a ServletListener class and listen on context shutdown events.

Alright, I tried this. In my ServletContextListener, I call a method on an EJB which creates the Hibernate SessionFactory and loads the configuration.

The problem comes in when I try to close() the SessionFactory per Gavin's suggestion: in my ServletContextListener.contextDestroyed() method, I cannot call my EJB (it's already unavailable, and I end up getting not authorized errors), so I end up calling SessionFactory.close() directly.

My log says this:


When my app restarts, it hangs setting up the JavaGroups stuff for SwarmCache:


It seems that the Hibernate SwarmCache provider isn't telling SwarmCache to shut down when I close my SessionFactory. A quick glance at the source code seems to confirm this: in the SwarmCache.destroy() method, the cache is cleared (which it should not be), but the cache is never removed from the group. In order to remove it, the CacheManager.shutdown() method must be invoked from the SwarmCache.destroy() method.