« Presumed Abort Transactions and availability | Main | GC and server tuning »

September 16, 2003

Faster CMP with WebSphere 5.0.2

Deferred insert functionality has been added in 5.0.2 as an option. This means that when the application creates an entity bean, WAS doesn't force an insert to the DB immediately. This normally results in at least 2 statements issued to the DB, one insert followed by an update with the initial values of the CMP. Deferred insert means that now WAS just issues a single insert with the final values which is clearly faster than the previous implementation.

This enables the deferred insert/create support. Add this to the JVM command line arguments using the deployment manager.

-Dcom.ibm.ws.pm.deferredcreate=true

Batched SQL support means that WAS uses the JDBC batching to send multiple identical statements to the DB using one command. This works really well with prepared statements. As an example, lets say we have a prepared statement 'INSERT VALUES(?) INTO T'. Before, when the application issued multiple inserts using this prepared statement, each one resulted in a DB RPC. Now, WAS can combine them and send them as a unit to the DB at commit time. This can result in a significant performance boost for the right application.

This enables the SQL batching support.

-Dcom.ibm.ws.pm.batch=true

So, CMP performance continues to improve and will continue to do so. I've run recent high volume database intensive tests and found that at high TPS rates (like 1000s), WAS was only taking 5-10% of the total response time (the rest is database). So, arguably at that rate at least, eliminating WAS would only shave 10% from the response time.

So CMPs are now coming in to prime time for me and whilst they certainly can be still further improved, may surprise you right now if you are used to the 3.0/4.0 CMP implementations. The thing to remember with CMP is that it is easier to do. I groan now at the thoughts of writing JDBC directly. So long as we've optimized the types of data access patterns that your application is using then performance should be fine. As usual, it depends on the application and there is no standard answer.

Note, to clear confusion, this only works with CMP 2.0 beans on WA 5.0.2 or better.

September 16, 2003 in WebSphere CMP | Permalink

Comments

The problem is not necessarily performance for toy examples, the problem that EJB is flawed as a model. It doesn't systematically and coherently address user needs.

The perceived user need is to isolate OO developer from a "foreign" paradigm (SQL). What you do with EJB is you replace a "foreign" paradigm (SQL that is) with another more ad-hoc framework, still "foreign" to OO dreams of magically persistent OO model(?), but the later one is an ad-hoc quagmire: CMP "model" and EQL -- not to mention descriptors.

Technically EQL is slowly set to reinvent SQL all over again, you can't really deploy it on complex business schematas (like accounting, financials, etc), maybe it's good enough for web shopping. When EQL will have SQL reinvented (plus some synctactic shortcuts), That will be a glorious day.

Besides the query language, more fundametally the model itself is mathematically primitive. It is "binary" E/R all over again, and this has been obsoleted for 2 decades one would think.

Small performance tuning on implementation mishaps really is really peanuts -- of it wasn't already bad that the database was taking 2 times the load of queries that were strictly necessary, the basic problem is the model is so basically flawed that in case of complex data access patterns the shape of generated queries is beyond repair.

Also the problem you discuss is murky in complex transactions where you insert related things in different tables. If ejbCreate -> insert is deferred, how will you make sure that you insert in correct order for the foreign keys to hold ?

So the question, what exact savings do we get when using CMP for all these limitations ? I and other friends have stopped recommending J2EE stacks as a solution until the folks working on specs and app server get serious about using CS instead of ad-hoc engineering hacks meant to patch. What is lacking is a vision and a methodic construction based on solid models and solid understanding of the domain.


I invite you to contribute to the pages starting on http://www.c2.com/cgi/EjbQueryLanguage
http://www.c2.com/cgi/EjbFlaws

Posted by: Costin | Sep 19, 2003 2:12:17 PM

Well,
We appear to agree. CMP works well for some applications depending on schema and access patterns and, obviously, not so well for others. This is almost a quote from the above blog.

EQL will likely evolve as you say with an OO bent and it'd be nice if it moved faster but it moves as fast as most things run by committees move.

The ordering issues associated with deferral and batch are real and it is something getting attention pronto. It's not just foreign keys, it's also to do with deadlocking.

I think you're over pessimistic with J2EE. It is successful, vendors sell a lot of it to customers who largely are happy with it. It gets better every rev of the spec and thats going to continue. The range of applications addressable with it increases and this will also continue.

It'd be great if it was perfect today but it isn't and the JCP will shuffle along and improve it over time.

Posted by: Billy | Sep 19, 2003 2:32:43 PM

Billy, after much pushing from myself and others, JBoss has finally done the same. What I'd love to know is why the INSERT/UPDATE implementation was preferred over delayed INSERT. My guess is the headaches one can get thinking about the CMR relations and ordering the inserts.

BTW, good to see you're not resting on your laurels.

Posted by: Jonathan O'Connor | Sep 23, 2003 6:57:38 AM

Post a comment