I just recently seen an implementation that used static methods and I am always trying to tread lightly with the use of the ServletContext and HttpSession.
My web container is hosting hundreds of these applications and I am concerned that this strategy might lead to problems in the future(running out of memory) but right now it is just my paranoia. I don't think the static method strategy will relieve my concerns with memory usage as the class will just live in another memory location? I know what your thinking "hundreds" of the same web application being hosted on the same web container? It was in my spec to have every client subscription to this application(service) have unique web application assigned. If I run into problems I might use RMI and place the service classes into the RMI registry. Any suggestions are greatly appreciate :-), Greg -----Original Message----- From: Michael Delamere [mailto:[EMAIL PROTECTED]] Sent: Monday, July 29, 2002 3:22 PM To: Struts Users Mailing List Subject: Re: Architecture advice.... Am I understanding you correctly that you werenīt happy with the first approach? What were your experiences thatīs getting you to rethink the matter? Thanks, Michael ----- Original Message ----- From: "Greg Hess" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, July 29, 2002 9:11 PM Subject: RE: Architecture advice.... > Hi, > > I have designed our service layer using normal classes, I initialize the > service layer on application start up and place them in the ServletContext. > I have been looking at this strategy and considering using Static methods as > well, as the only state in these classes is the jdbc driver and base data > source. My persistency layer implementation handles concurrency issues and I > don't think I would run into any issues having the application distributed > to more than one server. > > Wish I could offer more help, but I am in the same boat. > > Greg > > -----Original Message----- > From: Michael Delamere [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 29, 2002 2:15 PM > To: Struts Users Mailing List > Subject: Architecture advice.... > > > Hi, > > I had a discussion at work today concerning the best way to implement our > application. A very > basic discription of the framework would be the following: > > 1. Struts + Velocity for the view > 2. Struts ActionServlets for the controller > 3. Service layer/methods for querying persistence layer > 4. OJB persistence layer > > The main debate was actually about what the service layer would look like. > We thought about the following options: > > 1. The service layer consists of static methods > 2. The service layer would consists of normal classes > 3. The service layer could consist of servlets > > The idea is that (this is nothing new of course) the service layer would > purely have methods such as addToShoppingBasket() or checkLogin(); basically > service methods which carry out the communication with the persistense layer > and returns the result to the controller. > > The question is though, should we create a new object every time we want to > access a stateless method? Surely that would be a bit of an overhead. Go > with servlets? This possibly ties it to the web-container too much and > isnīt very elegant (?). Another option would be just to use static methods; > can this cause a problem when wanting to distribute to more than one server? > Is it better in terms of performance? > > I would really appreciate some help and ideas on this. It would make things > easier in terms of deciding on the next step. > > Thanks in advance! > > Regards, > > Michael > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
