Hi, I want to develop a web app. base on Tomcat + Struts and MySql here is my design
Action <--> BD <--> SF <--> DAO <--> MySql
Action: class extent Struts' Action
BD: A singleton POJO business delegate, deal with business remote interface lookup, transform exception to client related message.
SF: A singleton POJO session facade, preform all business login.
DAO: A singleton POJO data access object which encapsulate all database access matters.
and also has a POJO transfer object which pass around various tiers
my question is, is it appropriate to implement BD, SF and DAO as singleton?? They are all stateless but will it be a preformance drop when it handle a large number of request??
or I should implement SF and DAO as some object pool??
- Please comment on my design by Michael Mahemoff on July 17 2004 04:02 EDT
- spring by Matthew Wilson on July 17 2004 06:52 EDT
- Please comment on my design by Tomas Karlsson on July 18 2004 05:11 EDT
- Please comment on my design by lam yue on July 18 2004 10:38 EDT
- great by jamal lotfy on July 26 2012 10:43 EDT
Since they're all stateless, they can be multithreaded and you won't get a performance problem. However, there are a couple of other points to consider in this design:
- Singletons have numerous problems. e.g. difficulties with inheritance, lack of interface/implementation separation, distribution of instantiation logic across the application, duplication of boilerplate code, to name a few. Consolidate creation/retrieval of classes with a container framework such as Spring or Pico.
- What is the business delegate adding here? Remote lookups are probably the same for all entities. Transformation of business-related exceptions might be useful, but again could be acheieved by some kind of mapping framework. I'd consider (maybe you already are) working out a way to avoid hand-coding the business delegates, e.g. use a framework to bypass them altogether or automatically generate them if need be.
ditch the singleton pattern and let spring manage its state.
Hi, I want to develop a web app. base on Tomcat + Struts and MySql here is my designAction <--> BD <--> SF <--> DAO <--> MySqlAction: class extent Struts' ActionBD: A singleton POJO business delegate, deal with business remote interface lookup, transform exception to client related message.SF: A singleton POJO session facade, preform all business login.DAO: A singleton POJO data access object which encapsulate all database access matters.and also has a POJO transfer object which pass around various tiersmy question is, is it appropriate to implement BD, SF and DAO as singleton?? They are all stateless but will it be a preformance drop when it handle a large number of request??or I should implement SF and DAO as some object pool??RegardsFrom what I can see, you are not using the EJB container. This means you have to manage the transactions yourself in the Web container. The remote communication is from the Web container to the database. This means the BD does not add any value. (The purpose with a business delegate is to hide the remote communication and taka care of RemoteException.)
When it comes to the transactions, I have made many different implementations, and I have seen many more. Based on five years and +10 projects J2EE experience from one of the big system integrators (with +50000 employees), I will say most of them are incorrect. Many people are happy as long as the tests succeed and the application works. Most implementations I have seen work fine as long as all JDBC activities are commited. And most of them fail if someone makes a rollback! Common mistakes are to let many clients work on the same JDBC connection. (I have seen that in, at least, two projects. Total mess if one of the clients makes a rollback!) Another mistake is to miss the "atomic" property of the important ACID on transactions. Every line of code can fail, and if one click in the UI results in many JDBC calls to the database, data can be inconsistent if you are unlucky. Note that the JDBC connections you get from Tomcat has "auto commit" set to true, and this means every SQL statement you execute is committed directly.
If you really want to have 110 % security on tranactions (for example in a bank application), my advise is to involve an EJB container as a tranaction monitor and user stateless session beans on top of you JDBC code. Last summer, I made the database and application layer for a minor administration system with about 30 tables in the database. Entities used an optimistic locking mechanism. Two of the entities had more complex state charts, and worked in relation to eachother. (When I updated one entity in the business layer, the other one was updated as a consequence of the change.) Even with this minimal complexity, I ran into problems when managing the transactions on my own!
If the appliation is less critical, you can always say that you take a (project) risk and says that "rollback will never happen". Then you can simply use the DataSource from the Tomcat Web container, write the DAOs as a Singleton. Every method on the DAOs should should make a "get connection" from the JNDI namespace and close the connection when completed.
Hi ! thanks for the comments (really helps, ^^) and I think I should give out more details of my application.
The application won't contains many issue of transaction, the main function is similiar to some web forum. User can post/read something.
It will download message from some server, maybe tranform the content to another format, then send back to client upon request.
But it will do a little bit more since the application will transform/analysis the content before/after read by client.
The main concern should be speed because there will be a large number of concurrent accesses. It is the reason that I don't use EJB container and I think the application will barely prefrom a rollback, so I think the transaction management can be done by hand (me, ^^)
The reason of using a BD mainly because the application may use EJB sometime later, I want the design will let me scale up the application for minimun workload / codechange. Also the application will accept request not only from HTTP, but maybe something else like SOAP .. etc
I think break the application into multiple tier and let each tier do just enought thing will give me the greatest flexibility.
one more thanks to all u guys, ^^
I really like it it's marvelous.. you have a talent..