Comments on Kick me in the nuts: Something more scalable

I seriously doubt it given how we use it. It also ...

2010-04-25T17:33:14.298-07:00

I seriously doubt it given how we use it. It also serves a different purpose.

Jon, have you experimented with memcached instead ...

2010-04-25T12:12:51.082-07:00

Jon, have you experimented with memcached instead of ehcache, I don't have the statistics on hand at the moment, but I believe that would provide you with an even bigger performance boost then ehcache.

Unfortunately, I can't because we use the 'support...

2010-02-11T07:49:33.214-08:00

Unfortunately, I can't because we use the 'supported' EAP version of JBoss. You aren't supposed to change components at all in that version, otherwise you lose your support contract from Redhat.

We are running with full classloader isolation on and call by value. That was another recent change I made. It has vastly improved things for us because now ears with different jar files don't conflict.

As for jboss 5, that is a direction we are moving in at work, but it will take quite a bit of porting of our code (classpath changes, etc) to make it work. Part of the porting issue was that we were injecting the TreeCache into our beans and you can no longer do that with 5 (lame).

I'm *very* happy with ehcache now that I have it all setup and working well. We have JMX monitoring of it in cacti, it is very fast, it works well in our cluster. All of the issues we were having before with jboss cache are gone now.

Jon, you can always isolated the classloader for y...

2010-02-11T00:57:33.813-08:00

Jon, you can always isolated the classloader for your app and use a different JGroups/JBoss Cache or even Hibernate version. Here's one such example:

http://community.jboss.org/wiki/JBossCache2xand3xandJBossAS4x

Btw, maybe time to move to JBoss 5? :)

JBoss has a multi tiered classloader. I'm fine wit...

2009-11-12T08:12:44.445-08:00

JBoss has a multi tiered classloader. I'm fine with it being shared across all of my .ear files (server/default/lib/*), but the big issue is that hibernate (and jgroups and jboss cache) lives in there.

So, if you are trying to replicate your domain objects in a cluster, hibernate (et al) can't find them because it is in a classloader higher up the chain than your own objects.

The end solution is to put the caching layer into your own classpath so that each ear file has its own cache instance and to turn on invalidation so that there isn't any replication going on.

There is one more side issue which I need to resolve which is that I'd like to be able to turn on Disk based caching as well for my hibernate objects. We use @Enumerated enum's in hibernate and by default hibernate serializes the enums as objects instead of the toString() representation. Since hibernate is in a higher classloader, it can't rehydrate the objects from a disk based cache because the objects aren't in the same classloader. If I define my own @Type(type="enum") and implement my own hydration using toString/valueOf, that will solve this problem.

Surely that's the JBoss "everything is shared" cla...

2009-11-12T01:10:09.421-08:00

Surely that's the JBoss "everything is shared" classloader at work? You can turn that off somehow and are left with the problem of getting commons-logging back ends in at the level of commons-logging, JDBC drivers in high enough up for the DB engine to find them...