MDR-EdO: Welcome to Java Live! Today's guest is Akara Sucharitakul. Akara has a lot of experience with Java^TM 2, Enterprise Edition (J2EE^TM), and especially J2EE-related performance issues. For instance, he was one of the developers of the ECperf performance benchmark for J2EE. He's also the author of the recent article on the JDC, Seven Rules for Optimizing Entity Beans. He's ready to answer you performance-related questions about entity beans. So let's begin -- who has the first question?

test: Can you point me to some good coding examples that use Data Access Objects (DAOs)? I've looked at the sample code in the DAO Design Pattern. Are there other example sources?

akara: There are several places you can look for code using DAOs.

1. The J2EE Blueprints
2. The ECperf kit
3. The attached samples to the article Seven Rules for Optimizing Entity Beans

akara: Although you have a lot of control in BMP, the tradeoff is always the optimization. BMP will still be around for things that you cannot do quite as easily with CMP. For example I had to implement entities for persistent data that do not come from the database -- it might be from an LDAP server (HR records) or whatever else. In this case, you still have to use BMP. Good containers are already implementing optimistic locking for you. Key generation is another big thing under discussion, but it is not a problem doing it portably and in CMP. You might want to look at the ECperf kit's SequenceEnt and SequenceSes beans for an example; they perform well while being portable. Most containers currently handle multiple table mapping for you, so you should not have to worry about it That's true even in EJB1.1. Of course, EJB2.0 is much better at that.

David Byrden: Do real-life J2EE applications tend to be structured differently from the examples and patterns that are published by Sun and others?

akara: Older EJB code tends to be structured differently, especially when referring to EJB1.0 and containers that did not have entity beans at that time. The only things you had then were session beans. Code that came from those times certainly has no other choice. Redesigning code after moving it forward is a high cost venture. However, because it works well, people are not likely to change it. I believe that newer code will more and more follow the guidelines though.

udaman: Why should you use prepared SQL statements when accessing DBs?

akara: Prepared SQL statements get compiled in the database only once. The next time you try to prepare the same statement, the database will already have compiled the statement. It just needs to match it in the statement cache, but not recompile it. The result of this is a decrease in the database load, and an increase in performance of up to 5x.

mmccune2: Have you tested various CMP solutions (various vendors)? Also, what performance can you expect for BMP vs. CMP?

akara: In answer to the first question, yes I did. In answer to the second question, depending on the quality of the optimization and the quality of the BMP code you would otherwise have written, the benefits can vary from no benefit at all, up to 2-3x improvement in performance. If the BMP code you're writing is well optimized, you probably won't see more than ~50% improvement at this point in time.

Cedric: Do you think that distributing a cache of entity beans across servers in a cluster is a good optimization?

akara: This is really beyond what we've tested at this point in time. Considering distribution, there are many ways you might be able to distribute an entity bean. You can distribute it by type, by key range, or by duplicates. Based on my current understanding, I feel that distribution by type is going to work. Distribution by entity keys is usually achieved naturally as modern switches will most likely switch the same client session to the same cluster node. So that node will have the entities that the client accesses automatically. The only distribution approach I do not like is duplicates.

suresh: With EJB2.0 we have very mature persistence support for entity beans. However at the same time the deployment descriptor is becoming very complicated by defining each and every field of the bean and it's dependent class persistence fields. I'd love to see the requirement change so that only the field that is declared transient has to be declared in the ejb-jar.xml descriptor. Any comments?

akara: Deployment descriptors were fairly complicated in EJB1.1 already. With EJB2.0, the complexity has grown geometrically. I do not understand exactly why you want to have the transient fields declared in the deployment descriptors (especially why only those). My general feeling about deployment descriptors is as they get more complex, there's an increased need for good tools to manage them. No matter how much we talk about the details, things have to be declared somewhere. I'm really expecting this to be handled by the tools rather than by the author.

suresh: Akara, because the transient fields, compared with persistence fields, are relatively few. Even this is not necessary if you are able to manage with reflection to find out transient declared fields. Another interesting point is forcing to declare the field in DD's makes me wonder whether the spec is biased in favor of RDBMS than other persistence mechanisms. At least EJB2.0 should have address this issue but I feel it is not yet. Why?

akara: I have to give a lot of credit to the EJB2.0 spec team. They have done a great job coming up with a very comprehensive spec so far. However, there may be many ways to declare things that achieve the same results when you have to generate persistence code. So what you're saying is that you want reflection to find all the fields, and then negate away the transient fields in the deployment descriptors. Is that right? Unfortunately, you still have to have a way to map your Java field names to DB field names. So the suggested declaration does not provide continuity (you do not declare the fields but you map the fields). You may be right that RDBMSs are probably the preferred persistence mechanism at this time. So when people think, they think O-R mapping first. But it is definitely not limited to relational. You can use object databases for it, as well. I think there is much less need for other databases, so the specs might favor RDBMSs over others.

Roger: Can you comment on database vendors support or lack of support for 2 phase commit, which has been in the EJB spec for a while now? And what do you make of performance when using 2PC?

akara: I know it is part of the specs, but I'm still not convinced that it is the way to go when you design an application. Unless you have no other choice, I'd rather not to use 2PC. That's because the overhead for global transactions is rather high. So for 90% of the EJB users, I feel that the lack of 2PC support in the database won't hurt them; that's especially true if you look forward to EJB2.0, with its better support for asynchronous messaging. I'd prefer to use reliable/transactional messages to synchronize between distributed databases rather than 2PC with synchronous updates. The performance you see will be radically different.

mmccune2: Can you list the most critical rules (out of your 7) for optimizing entity beans. I haven't read your JDC article. Thanks.

akara: In fact, there is no most critical rule. I believe all of them are very important and one leads into the other. In fact, at the JavaOne session I added another one which is all about key generation. Without repeating the discussion, I'd suggest you to look into the ECperf kit (as said previously, SequenceEnt and SequenceSes beans).

test: What are the performance implications of using an entity bean that maps to a table without a primary key?

akara: The table might not need to have a primary key (in SQL semantics) but the entity bean certainly needs to have it defined. It's part of the DD. Basically, if you define a primary key in the table, a unique index is created (at least on the DBs I know). This will increase the performance on a findByPrimaryKey call on a large table. Otherwise you might not even need one and there might be no performance difference at all. But again, you'll need to declare it for the entity bean as part of the deployment descriptors.

MDR-EdO: Well we've quickly come to the end of our session. I want to thank all of today's participants. We had an interesting set of questions. And of course I'd like to thank Akara for his excellent answers.

akara: It's great to have you all on the forum. If you have additional questions, I'm monitoring the J2EE interest mailing list and if I find it appropriate to go in and answer I'll do so. Thank you very much and good luck!

MDR-EdO: Last moderator (me) signing off. The forum is now unmoderated.

Reader Feedback

Tell us what you think of this transcript.