I'm using CMP/CMR/CMT in WebLogic 7.0sp4 and Oracle 9.2 on Windows XP and Solaris in a production environment. I am, however,
not in the systems group -- I wrote the code.
First, a suggestion: use XDoclet or some other tool to generate home and component interfaces, deployment descriptors and value objects. You will save countless hours and avoid frustration this way. Writing deployment descriptors by hand is torture, even with a good XML editor. Keeping them up-to-date is even worse.
The application seems to perform well enough in production. Our development box (for smoke
testing) is a two-node cluster, and it seems to sag every so often. Keep in mind though that it gets thrashed, being deployed to constantly, so often the slowness is due to compiling JSPs and empty caches.
Our tables include several tiny ones (1-1000 records) used for lookup and system data and a few more large ones (100,000-1,000,000 records) for user-related data. Unfortunately, I cannot say that the entity caches have been tuned as we don't have anyone with that level of systems experience here (or perhaps no one has made the time?). So I made semi-educated guesses and hoped for the best.
What I can definitely say is that the database continues to be the bottleneck. We're not using entity beans across the board, and the concensus is that it's the uncached
JDBC code that is pounding it. One thing that helped a lot is moving to Oracle RAC where the database itself is clustered.
Having said all that -- and not to convince you to do the same -- we are moving away from EJBs entirely. I'm currently prototyping a Spring/Hibernate solution that will use Tangosol Coherence for caching of domain objects. The main reason is that WebLogic is much too expensive given that we're not making use of the other features.
Hibernate will cover persistence very well. We've used this on other projects here with success. Spring will handle the application context and manage business objects. We aren't using any distributed features (web and
EJB tiers are co-located), and our minimal usage of JMS could easily be replaced with something simpler. Finally,
Tomcat will provide the
servlet engine.
It's going to be an interesting jouney, that's for sure!
