Using stateless EJB vs. entity EJB

[maxut]

Hello all.

I'm new for J2EE architecture and I have to design a web application's business entity, which will be accessed a lot with read only mode and very little with update purposes. The number of such entities in the system will be restricted (they are going to be about 350-400). What is the right way to design EJB for such an entity. It seems that because there is no concurrent updates it is better to design stateless EJB with database access in every business method for every client. From the other hand, I see that JBOSS maintains only one instance of entity EJB per JBOSS instance, so I don't need to access data base every time, since I can rely I always have a synchronized data inside the bean. So, using entity EJB I can benefit from saving a lot of DB accesses for every 'getData' methods calls.

Any suggestions will be appreciated.
Thanks in advance

[kanagawa]

Hi-
I'm fairly new to J2EE, as well. However, I've had some recent experiences you might find illuminating. If you're going to use an entity, you'll have to decide whether to use BMP or CMP. There are some drawbacks to using CMP, especially if the bean isn't updated frequently. Most of these drawbacks can be fixed with configuration of JBoss, but you have to work at it a bit. If you're very comfortable with JDBC and SQL, already, you might have better luck with a stateless bean or a BMP bean.

If you depend upon a CMP entity bean to be both a read-only data source and a writable entity, you're going to have 2 basic problem. First, you may encounter dead-lock exceptions when beans interact with your entity (admin guide pp. 180 - 190). Second, you may experience performance below your expectations. I've had both these problems. Lucky me.

By default, only 1 transaction can access the entity bean at a time (transactions lock the EJB). JBoss tries to detect dead-lock and throws exceptions when it thinks its identified a dead-lock situation. The default configuration is "safe" and throws alot of exceptions when they aren't really dead-lock. To avoid this, you'll need to explicitly mark your interface methods read-only, which prevents those methods from triggering a lock on the entity (as I understand it). If you mark the entire bean read-only, it'll never participate in a transaction and dead-lock isn't a problem. Of course, you can't update the data through that bean, anymore.

You can avoid some of the dead-lock headache by using the "Instance Per Transaction" configuration for the bean (admin guide p. 187). This creates a separate instance of your bean for each transaction that wants it (which nearly eliminates dead-lock), but it makes things slower because JBoss refuses to cache the entity and therefore reads it from the DB every time.

You can also choose to mark the entity for commit-option 'A' or 'D' under the (default) "Standard" CMP configuration (see admin guide p. 180). This caches a copy of the bean in the JBoss and so it only hits the database when it feels like it needs to do so.

We've spent alot of time tweaking our JBoss configuration lately. It seems worth it but some of the more experienced java programmers I've talked to lately have been telling me I should just "avoid CMP" altogether, given the performance limitations.

As always, your mileage may vary. Hopefully, this is useful information. You can read the CMP docs (chapter 6) and the admin guide (Chapter 5 section 17) for more information.

[georgerjm]

Hello,

I think you should distinguish between the use of session beans and entity beans.
Session beans are used for implementing business services tier whereas entity beans (BMP/CMP) are used for implementing business domain tier.

The business domain tier is used for representing your application object model. you can resolve there objects relations (one to one, one to many, many to many), and objets integrity.

The business service tier is used for performing action like :
- calculate customer bill
- perform client registration

you can use or not use EJB for implementing business service or business domain tiers but you should implement both of them.

you can decide to not use entity ejb but you can't replace them by session ejb, because these ejb aren't used in the same way. Then you will probably use your own business domain objects.

i will be happy if this could help you

[maxut]

Thank you for all replies I have received, and sorry for not notifying it: I'm talking about BMP entities with 'B' configuration and 'isModified' method, that allows me to avoid unnecessary DB updates. Also, of course, I implement both business services and business domain layers, but still I have 2 ways to implement business domain; with entity EJB or stateless session EJB. Let say that I frequently asked to return caller the last data from DB about a specific entity, so every time I can access DB, collect all necessary information, and return it to the caller (stateless EJB impl.), of course in this case, my bean is not representing any specific entity, but it's a sort of global util for the specific class of entities. Or I can just return the current inner data of my bean, without any DB access (entity EJB impl.). Those ways seem me very similar in terms of result I will get, but my question is what way is better in terms of performance and correctness from J2EE design point of view.

Thanks for your replies.