Hi, That would depend on the kind of persistance requirement you have. 1.Stateless is used for better performance and when state of the client need not be stored. 2.Stateful session beans would be used when the requirement is contrary. 3.CMP is helpful for faster development of the persistent mechanism and if compilcated SQL's are not involved in implementing the business process.
Joined: Oct 10, 2006
I would also like to add that DAO only serves the purpose of decoupling the beans from the database access.It would also make sense to use them, if you are expecting schema switches or database switches.
Joined: Nov 16, 2006
>>>That would depend on the kind of persistance requirement you have. Agree with you.
which one would you choose from the below two options
1. Stateless session beans(acting as facade) --> BMP entity bean -- > DAO(will handle the persistance)
2.Stateless session beans(acting as facade) --> DAO -->(will handle the persistance)
Assuming a scenario that user must write code to handle the persistance in DAO, the second option is more simpler because it does not have the extra layer(of BMP entity bean). My question is "Is there any special advantage of putting that BMP entity bean layer in between session bean and DAO. Does it improve the performance or do you think we can avoid it?
Rich has told you that if you worry with thread access synchronization by multiples clients to the same entity, BPM entity beans could improve the system synchronization.
Remember that each entity at your database will be mapped for one entity bean instance managed by the ejb container. Without entity beans (CMP or BPM), your DAO code must ensure that multiple transactions does not override the business data.
Transaction are complicated to maintain with programmer code, you have to believe that isolation levels and transaction scoping will help you to manage this.
But in fact, distributed application require extra runtime code to manage multiple access from remote clients (web application, CORBA Clients).
This is the motivation for Entity beans. If your application does not worry with multiple access at the same time, only a data access layer with DAO components is enough. At most enterprise projects, this is really enough, but try to figure it out the submarino.com application or the travel reservation system, that need to access the same data, by multiples clients ?