EJB CMP 2.0 performances flaw


EJB programming & troubleshooting: EJB CMP 2.0 performances flaw

  1. EJB CMP 2.0 performances flaw (4 messages)

    One of France's most prominent computer science magazine titled in his last issue: "J2EE makes the e-business edifice stumble". That's no good news.

    This was based on a survey by an independent consulting firm using WebLogic 6.1 running on a Quadri Xeon / 1 Go Ram, 4-500 MHz running under Windows NT4 connecting to an Oracle 8.1.6 Bi Xeon / 320 Mo Ram 2-400 MHz Windows NT4 server.

    The survey concluded: that though two months of sustained effort, involving a BEA consultant, their test application couldn't stand more than 50 users at a time. The weakest link was identified as being the CMP Entity Beans. The survey advises to wait another couple of years before to use CMP EJBs so as to give time to Sun to mature the persistance mechanism.

    Has any of you any element corroborating or denying this ?
    What about the EJB 1.1 ? Using a J2EE 1.2 application server, capable of running EJB 2.0, that may be a trade-off.
    Is EJB 1.1's CMP mechanism any better ?

    Threaded Messages (4)

  2. EJB CMP 2.0 performances flaw[ Go to top ]

    I believe that Sun only defined the spec of CMP2. It's the container providers who implement the underlying mechanism. And I don't think EJB1.1's performance can be any better than EJB2. In fact, WLS 6.1 is what you said "a J2EE 1.2 application server, capable of running EJB 2.0".

    The solution? Some would say O/R mapping products, like TopLink or CocoBase would help. However I don't think so. Adding an extra O/R mapping layer in addition to entity EJBs will complicate the system even further. Adding such a layer may seperate the database and application servers, and thus increase the flexibility quality of the whole system. As for performance, this is a big question mark.

    Maybe if performance is your primary concern, you should implement your own persistence service that's light enough to out perform entity EJBs. Yes there are features that you do not needed in EJB2 spec. However it's no easy task, you know. :)
  3. EJB CMP 2.0 performances flaw[ Go to top ]

    This is simply not true. With the introduction of abstract accessors, the container can implement eager/lazy-loading strategies. This means that the container can load in just a few queries (usually one) all of the data required for a transaction. I would be willing to bet that in an average application (not a benchmark app) that the programmers would be hard pressed to beat the performance of a well-written EJB server.

    I would put the blame for the performance problems squarely on the choice or hardware. First NT 4 has never been able to efficiently use 4 processors, and these are 500 mzh processors. Are they running the database on the same platform? Is the database SQLServer? Are they using a well written JDBC driver? Finally, Java has problems on multi processor boxes (may be JDK 1.4 will fix this). I always suggest that people put the J2EE server on a cluster of $1500 boxes running Linux and JBoss.
  4. They're running the Oracle 8.1.6 database on a Bi Xeon / 320 Mo Ram 2-400 MHz Windows NT4 server. I don't think the driver is involved here as I used it many times for other applications and never came across any pb with that.

    As for the results they've got, sadly enough, you have to pay $ 2000 to get extra details in order to buy the complete survey.
  5. I have a survey that proves EJB 2.0 can handle 1,000 users, and mine only costs $1,000!