I have a design question regarding the number of EJBs the container creates at its start-up time and singletons.
1- If the number of beans can be declared in the xml file of the app server, say 1, what is the need for a singleton design?
2- What does it mean to set the number of beans to 1 in the xml file/have a singleton?
3- If I set the number of beans to 1 in the xml file, does this mean that there will be one bean per row of database entry, or just one bean period? Let me elaborate: My bean represents a row in the database, so say there are 2 clients requesting the same data; Does this mean one has to waite untill the bean is done servicing the first request? And what happens if another client requests a diferent bean for a diferent record concurrently?
4- How can I ensure that I have 1 bean per database row?
5- Is this a good design pattern?
Thaks in advance
Interesting... I am assuming you are talking only entity beans here.
This is what I think...
If you set number of beans to 1, then only one request (be it for any row in your database) can be processed at any time. Other requests should get CreateExceptions/FinderExceptions. After the request is over, the container may passivate that bean to serve another request. It is like having only 1 waiter (instance) to serve all the tables (requests) in a restaurant.
Why would you like to have one dedicated bean instance per database row? You should reconsider why you are using entity beans, maybe.
Well, it is a decision handed down to me...
I am wondering how would a singleton behave? Would other clients get a Finder/Create Exception if concurrent requests are made?
How can I make sure that only one bean exists per record? I just do not want to allow multiple beans servicing clients for a given record. Say three different clients request record mm67. For me it is OK for the two clients to waite untill client one has finished with bean. What I do not want to happen is to have three beans servicing the clients for the same record.
Thanks in advance
Rasoul, What is wrong or why don't you like to have a pool of entity beans representing a single row? It is the property of entity beans and the container will take care of concurrency, if the appropriate attribute is set. I think serializable attribute will be equivalent to your requirement.
Well it is the ejbLoad, and ejbStore which are called after each business methods. I have set the intelligence to take care of the ejbStore, but the load is a bit more tricky. It is the belief of the MIS dept. that such an architecture will not scale. So I must instead come up with an alternative. I thought that singletons may provide the answer. The alternative was a timer. But then the problem of timer synchronization of multiple entity beans for the same record arise.
Any thoughts on that...
If you don not want to use the EJB pooling concept, there is no point in using EJB. I think better you could use simple JDBC call and also Singleton is not permitted in J2EE.
Thanks for your response.
I guess I have to come up with a different architecture.