EJB design: Entity Bean and DAO

  1. Entity Bean and DAO (7 messages)

    Hi, I would like to implement data access layer using custome DAO. The application doesn't involve a great deal of transaction problem, most are select, sometime update queries to database.

    If I implement DAO as singleton, what would happen if concurrent access to that DAO?? I know it will multithread, but deos it means that only one request can be process by that DAO at a give time?

    What happen if a huge number of request are made concurrently?? Would I get preformance benifit if I implement multiple DAO and use an object pool instead of using singleton DAO ??

    any framework beside EJB can help me?
    Thanks for help


    Threaded Messages (7)

  2. Entity Bean and DAO[ Go to top ]


    First of all, I you have most read access to data, you should go for (stateless) session beans. You cannot benefit of the the value of entity beans unless you have updates of data as well.

    If you implement the DAO as a Singleton (which I recommend you to do), you should get a JDBC connection from the InitialContext in every method on the DAO. And close the connection (that is return it to the pool in the application server) within the same method. Do NOT get the connection in the constructor, store it as an instance variable, and use it later. Then you will run into concurreny problem.

    Don not make a pool of DAOs. The synch needed to manage the pool is a potential bottle-neck.

    If your application is small, and you don't expect it to grow in the future or live for long time, I recommend you to use JDBC directly from the Web container. EJB introduces some overhead in runtime, but most of all it introduces a lot of overhead in project. At least in small projects.

  3. Entity Bean and DAO[ Go to top ]

    Hi !
    If all the DAO are singleon, do I need to mark each methods as synchronize??

    I just wonder if all DAO are singleton, what would happen if a large number of requests are made to that DAO? I know the DAO would be multi-threaded, and does it means that only one database query can be made at one time (because all method in DAO are marked with synchronize) ?

    or if I use a DAO pool, more than one request can be made to difference DAO. However there should be only one connection / query can be made to database, so I think the preformance is the same as singleton's DAO, am I right??

    Also my application is rather simple, but it will have a huge volumn of traffic. Most DB query is read only so it doesn't involve many transaction problems. Do my design still fit for huge traffic? or I should use stateless session bean WITHOUT entity bean ??

  4. Entity Bean and DAO[ Go to top ]

    Also, it is entirely a web application, so all the web container and database are within one machine, or within a cluster of machine. The application won't preform remote lookup and execution, if I use stateless session bean, does it introduces overhead becacuse all of thr RMI stuffs ?

    However by using stateless session bean, I don't need to care pooling, caching etc....

    um.. tough decision

    Any help?

  5. Entity Bean and DAO[ Go to top ]

    Hi again!

    Using sateless session beans will introduce RMI calls, even if the Web container and the EJB container is on the same machine. The reason in that the EJB specification requires "call by value" (meaning making a copy of the objects in the argument list) every time you make a call. However, most application servers should implement faster protocols than the standard Java RMI protocol for this. (I know WebLogic server has such protocols, and BEA says that their own protocol is about 100 times faster than standard Java RMI.)

    So of you have a lot of read-only operation to the database, I think the simplest solution is to go for Singleton DAOs executed in the Web container. The DAOs must be fully stateless and every method has to get (and close) a connection from the connection pool in the application server.

    However, if you expect the application to grow (once you have shown the value of it to the customer) and include transactions in the future, go flr stateles session beans now.

  6. Hi,

    I agree that a stateless singleton DAO is probably the simplest way to solve your problem. However, you can run into a couple of problems:

    - Singletons are tricky to unit test
    - Its a hassle to switch to a stateless session bean approach in the future.

    At the risk of sounding like I'm jumping on the Spring bandwagon, I'll say this: I've recently been experimenting with Spring (http://springframework.org), and would strongly recommend it for your case.

    Spring abstracts away the implementation detail of your DAO class, such that switching between a POJO DAO and a SLSB facade requires no code changes in your web tier - it's all done in an XML config file.

    Here's what I would do:
    - Write an IMyDAO interface and a MyDAO POJO bean that implements it. MyDAO should get and release a JDBC connection inside each method, as previously mentioned.
    - In your web tier, use a Spring BeanFactory to get an IMyDAO object. The decision to return a MyDAO rather than a stateless session bean is set in the XML configuration file. You can easily rewire to use a SLSB in the future. The web tier has no knowledge of which IMyDAO implementation is being used.
    - Call methods on the IMyDAO object.

    No sweat, and no need to write any complicated code!

    A few tasty extras with this approach are:
    - If you're using Spring's MVC framework, it becomes even easier to get instances of your configured beans.
    - You can make methods transactionally aware, a la EJBs, just by adding some stuff in your config file that generates a transactional proxy for your implementation class.
    - Spring comes with some Hibernate DAO abstract classes that you can inherit your DAOs from to make things even simpler.

  7. Hi ! thanks for all the advices !
    The application will grow and scale up to cluster in the future, so I think using stateless session bean is the right choice

    I also heard of many good comments on Sring framework. However I am still a J2EE newbie, I want to practice my J2EE skill first then to look for someothers framework

    One thing about the DAO, if many DB query are read-only, should I use DAO or Entity Bean?

    If I use DAO, I need to do caching myself and it is definitly not enjoyable.

    If I use Entity Bean, how can I control the caching? The data in DB is updated by some other background Java programs and then send to web client as read-only data. Can I control the refresh rate of EJB and tell the bean to cache up all data until next refresh ??

    I think I need a refresh rate of 10-20 seconds, does this make sense?

  8. Entity Bean and DAO[ Go to top ]


    As long as you don´t have any instance variables in the DAOs/Singletons, you don't need to synchronize. The local variables declared within every method will ge it's own copy for each thread calling the object. Many threads making calls to the same object (and to the same method!) at the same time will NOT share data.

    This also means you don't have to synchronize the DAOs.