1. What are the criteria for deciding to go for entity bean. If data caching is the only reason then does that mean I do not have to use it for data I do not want to cache.
The criteria for choosing entity beans is pretty difficult. You need to consider database schema, transaction, useage and performance characteristics. I wouldn't bother with caching as a criteria as caching is easy to implement elsewhere (especially for reference data). In particular:
- Does your database schema match the entity model neatly. I.e. can you map each entity to one row of one table. If you can't then you may need to consider JDBC or an O/R mapping solution.
- Does your data need to be transactional? Entity beans are fine for transactional usage but can have an unnecessary overhead for read-mostly and non-transactional data
- Do your use cases dictate only working with a small number of entities at any one time? Entity beans are great where each use case only works with a handful of beans. They are a very poor choice if you need to access hundereds or thousands of bean instances at the same time.
> 2. Does it make sense to use EJB for static table lookups. If so will there be any problem if I use JDBC for maintaining these tables?
Many people avoid entity beans for static table lookups. Where the lookup is for a tiny number of items the effort in writing the bean is a waste. For large lookups the performance hit can be huge. Personally I'd suggest using JDBC for reference data and chaching the data in memory in the layer where it will be used from.
> 3. If I use CMP for my entire database, I cannot have a denormalized data model, but does CMP do away with the need for de-normalizing?
This is a major problem/weakness of CMP. Each entity bean can only map to one row in one table. If you have full control of the database schema or the schema maps nicely to your beans then CMP is an option. If this is not the case then I'd recommend normalising and tuning your database properly and using a different persistence strategy such as JDBC, JDO or an O/R mapping tool. Database schemas are normally more pervasive over time than the applications built on them, thus getting a well tuned database willprobably give you much more success in the long term.