Late Friday I cut the first CR for Naga - 3.0.0.CR1 is now in our Maven2 repo and on jboss.org for you to download.
There are a host of new features, fixed bugs and performance tweaks in CR1 - check out the release notes on JIRA for the details.
Finally, I would like to add that this is not strictly a CR in that I can't release this as a GA. The documentation - FAQs, user guide and tutorial - still needs to be brought up to date with all the new features in Naga, but apart from that, the code is ready for the prime time. Pending feedback, bug reports, and the like, of course.
So, please treat this release as something close to prodution quality and feed back as much as you can on the user forums - this is really important to us. What I am particularly interested to hear are, in addition to comments on new features:
- Performance under load
- Performance in large clusters
- Backward compatibility against code written for JBC 2.x
Cheers
Manik
Posts
8 comments:
Does the "Backward compatibility against code written for JBC 2.x" mean that Naga should work with Hibernate 3.3 as a second level cache?
Well, I have run the Hibernate trunk (3.4.0-SNAPSHOT) testsuite with 3.0.0.CR1 and there are no problems. But this is using the default locking schemes set by the test suite, which is optimistic and pessimistic locking.
We just need to prove that using MVCC as a locking scheme doesn't break things either, but I can't foresee how it would at this stage.
Would be interested to hear about your experiences in using Naga with Hibernate. :-)
I haven't seen POJO Cache 2.2.0 GA yet and you are going to have Cache 3.0.0. CR... Oh gosh.
POJO Cache 2.2.0.GA is only held up on a dependency going GA (JBoss AOP 2).
I just tried 3.0.0.CR1 with Hibernate 3.3 as a drop in replacement for 2.2, and I get the following error:
java.lang.NoSuchMethodError: getInstance
at org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.createSharedCache(SharedCacheInstanceManager.java:191)
at org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.start(SharedCacheInstanceManager.java:148)
at org.hibernate.cache.jbc2.JBossCacheRegionFactory.start(JBossCacheRegionFactory.java:106)
at org.hibernate.impl.SessionFactoryImpl.init(SessionFactoryImpl.java:192)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1304)
Thanks for the stack trace, Austin. This has to do with a deprecated singleton instantiator on the cache factory, which I removed, and have now reinstated. I have also fixed Hibernate trunk so it doesn't use the deprecated instantiator.
Until you see a new release of JBC 3.0.0 *or* Hibernate, you could grab JBC trunk and build off that.
Thanks. I did a build of the Hibernate adapter from the 3.3.1 source using the constructor instead of getInstance(), and everything seems to work fine now.
I notice MVCC uses significantly less memory for my use case compared to both 2.2 and Coherence.
Also, see this email thread on the JBC dev list:
http://lists.jboss.org/pipermail/jbosscache-dev/2008-October/002525.html
You shuldn't need to recompile Hibernate 3.3.x either if you use a snapshot or release newer than JBC 3.0.0.CR1 (just publishing a new shapshot as I type this)
Great to hear about the improvements in memory consumption. :-)
Post a Comment