Kri, Why are BMP and CMP the only two options. If CMP does not perform acceptably, you have to write code yourself. Then you are better off using some other persistance mechanism behind a session facade.
Originally posted by kri shan: Hi Jeanne, instead of re-inventing the wheel, i would like to use existence persistence mechnaism
I agree completely. Note that while BMP provides a persistance framework, you still end up writing most of the code yourself. I think it is really between CMP and one of the technologies Paul listed.
CMP supports DB portability. BMP supports Application Server portability.
This implies that CMP is not portable across app servers. You have to regenerate the deployed code, but it isn't inheritently unportable. That said, I would go with Hibernate if I was starting a new project, could choose and didn't need the security/transaction/scalability support of CMPs.
Joined: Apr 08, 2004
Whether Hibernate, Toplink, OJB, JDO provides all EJB container provided services(Security,Tranasaction,..) other than Persistence?
No. But why would you need them in a persitance layer?
Joined: Apr 08, 2004
If i use Hibernate, Toplink, OJB, JDO, i have to use EJB container provided services / i have to write the code for Tr,Security... Hence one more extra layer/tier comes here ( Tr Layer + Persistence Layer). Whether is it a good design ? This is my doubt.
No. You just call your persistance layer methods from an EJB.
Joined: Sep 25, 2002
Its seems to a lot of ppl are confused and seem to think that BMP means EJB + handwritten SQLs. It does not.
BMP just means EJB + manual persistence, whether i handwrite the SQL or use an OR Mapping tool (hibernate, ibatis, custom made, etc). If you use hibernate from your EJB, then you still get CMT provided by the app server plus the nifty OR Map provided by hibernate, so its a win win.
Here's where we typically apply the DAO pattern. So if one day you feel like switching from hibernate to handwritten SQLs or some other OR solution, just implement a new DAO to wrap that and plug it in. Your EJBs working on the DAO interface wont even know you switched implementation and the container could care less, it calls your EJBs with whatever txn attribute you declared and commit/rollback/resume/etc the txn after your ejb method completes.
Joined: Aug 03, 2002
Infact what is suggested is you can use the persistence layer of Hibernate and call those methods from a Stateless Session bean and there you can put your transaction attributes also.