Originally posted by saahil sinha: Hi , I would like to know when one should use container managed persistence and when to use bean managed persistence.And the advantages of one over the other.
CMP gives you a lot of things for free--you don't need to write SQL, you don't need to manage database connections, etc. On the other hand, if you need more complicated queries that CMP's Query Language (EJB-QL) cannot be bent to, then it's probably better to use raw JDBC or BMP. With BMP, you get life-cycle management for free but you need to write all database access code yourself.
I think the real question is why someone would ever want to use BMP. The benefits of using CMP are very clear: persistance for free. I've always liked this quote from Bruce Tate in his book Bitter Java: My first question when I saw I could create entity beans with bean-managed persistance was, "Why would I?" Isn't that like ordering a hamburger without the meat? "Yes, I'm ready to order. I'll have a persistence framework, hold the persistence." In my opinion there is no good reason to use BMP. They offer nothing over a simple Session Facade + JDBC.
In my opinion there is no good reason to use BMP. They offer nothing over a simple Session Facade + JDBC.
Unless you count consistency. I haven't personally encountered a need to use BMP but I could imagine a situation where you'd like to preserve a degree of consistency among your persisted domain objects (i.e. the same API for all domain objects, which are either CMP or BMP). Does this "consistency" sound like a valid rationale for using BMP instead of raw JDBC?
One reason we used BMP is because we needed a bean to represent fields in multiple database tables and our app server didn't support that. Those where pre 2.0 days, but with EJB 2.0 that is very little to vindicate the use of BMP.
BMPs, though much vilified, could prove useful where the relational database has been derived from a legacy application and there is a need to write a nice object layer over it. In these instances, often a design nightmare, is to achieve the right object to relational mapping. where such design constraints do not allow for proper CMP design ( although, i must admit this argument is more tilted towards those who are in EJB1.1, which I suspect plenty still are), BMP provides the vehicle to obtain objectisation of a relational schema.
If CMPs are so useful, why do we have DAOs coming into picture now... ? As your app gets more and more complex, you will slowly move away from CMPs...to BMPs or even just plain SLSBs.. Usage of Entity Beans is fraught with problems, if not used wisely. Consider a finder method, which returns just a few objects... your database size grows, and before you know , your finder method returns 10,000 objects.... and there goes away your performance and memory...out.
Jitender, if your findAll() is returning 10,000 objects; can we write our own finder method that will return selective subsets of data rather than 10,000 ? Displaying 10,000 records is not feasible. Does EJBQL (EJB2) support some sort of filtering syntax e.g. LIMIT in postgresql or TOP in Transact-sql. ? Gavin
It doesn't support but not sure that if any app server supports this as an proprietary feature.
Originally posted by Gavin Bong: Jitender, if your findAll() is returning 10,000 objects; can we write our own finder method that will return selective subsets of data rather than 10,000 ? Displaying 10,000 records is not feasible. Does EJBQL (EJB2) support some sort of filtering syntax e.g. LIMIT in postgresql or TOP in Transact-sql. ? Gavin