Use of DAO Vs StateLessSession bean
Hi,
I have been using the DAO J2EE design pattern for bulk data acces from the database avoiding entity beans,.. But what is happening is that I have factory which creates the instances of DAO's and that factory is used by a Session Facade, I do feel that I can get great benifits of performance of StateLess Session beans if I use Stateless Session beans to access Database as instaces are pooled and Session facade can use another stateless session bean doing the doing bulk data access.
by using Stateless session bean instead of DAO,...do u think I will get better performance
thanks
Jay
[631 byte] By [
muttu] at [2007-9-26 15:26:47]
If you have a very high load, StatelessSessionBeans might give you better performance due to object pooling etc, but the disadvantage is the remote call, so if the load is not that high a DAO makes more sense.
Many people will tell you that because EJBs create pools of objects they are faster. However, if you create a DAO with static methods for accessing the data, there are no objects to worry about.
This is really just a design issue.
If you plan to call these Access Methods from one client only, I suggest using statis DAO objects. No overhead, no remote calls, no objects to pool. If you utilize a DataSource or other pooling mechanism, you will be fine. This method is the quickest, however if you later want additional clients to utilize this they will most likely have to provide their own connection and load the DAOs in their own VM.
If you plan to call these Access Methods from more than one client, you may be better off using Stateless Session Beans. The benifit is that all clients will share the DataSource since it is created on the EJB side. The drawback is that your DataBeans (or whatever the EJB returns) must be serializable (unless you use the Local Interfaces) AND the DataBeans have to be serialized, sent over the network and then un-serialized.
If you have time a good middle ground is to implement the EJBs as Local EJBs at first. This allows you to place the DataSource in the EJB tier. Since you will be using Local calls, the serialization and network hit will not be required. This requires as much work as using normal EJBs, but is very close to the speed of static DAOs. If you later need to add remote clients to the mix, simply create the RemoteHome and Remote intefaces. The underlying bean and Local stuff should not be effected. As long as the return objects can be serialized, this will only require and addition to the existing server code with no change to the original (Local based) client code.
