This is exactly what I'm doing (the instance level BusinessDelegate coupled with a singleton ServiceLocator), but I do not cache the EJBHome objects in my ServiceLocator simply because most containers do that on their own now, and doing so somewhat limits the JNDI look-ups to be consistent system wide (probably a good idea anyway, but can be limiting). My BusinessDelegate actually caches the remote reference to the SessionBean that it uses (via the javax.ejb.Handle), thus eliminating further look-ups for that BD. I like avoiding having to do multiple instantiations and look-ups, just have to be cognizant of memory utilization when programming like this. The preliminary tests that we have done so far indicate that this model scales very well.
Anyway, this was really the reason that prompted me to ask the question. I wanted to make sure how Struts would handle the Action classes to ensure that no synchronization (or the like) was happening (hadn't looked into it myself so I just asked, shoot me for being a little lazy). Because some of my SessionBeans are pretty massive in their functionality, I couldn't have multiple requests for the Action class waiting for execution. That's why I'm happy for the assurance that Struts functions the way I assumed/hoped it would. --- Hal Deadman <[EMAIL PROTECTED]> wrote: > I do make my Business delegates instance variables of my > Action classes > because they are thread-safe (and the controller does have to > depend on the > model). They are light-weight objects but it's nice that I > only have to > create them once, which I can do in the constructor because > there is only > one instance of each Action. > > My business delegates use a singleton ServiceLocator class > that caches the > InitialContext and EJB home interfaces that are looked up > (thank-you EJBX). > I rely on the container to make creating session bean remote > interfaces > efficient. > > If someone is doing Struts, they should already be familiar > with the way > Servlets&JSPs have to be made thread-safe so I don't think it > should be a > problem for novice programmers. > > I am not trying to come across as an authority, I am just > speaking from my > experience and I like the fact Action classes are only created > once. > > Hal > > > -----Original Message----- > > From: Steven D. Monday [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 13, 2002 9:53 AM > > To: Struts Developers List > > Subject: RE: Scalability question > > > > > > > > Hal, > > > > Thanks for the reply. I don't think I was attempting to > make > > a point as > > much as learn some of the rationale behind the choice of a > > single action > > instance as opposed to creating an action instance perhaps > upon every > > request for example. A couple follow up questions. > > > > > Action classes aren't supposed to have any kind of serious > business > > process. > > > > I didn't mean to imply that an action class itself would > > implement serious > > business logic itself. However, unless I'm misunderstanding > > the role of an > > action class I would assume that it would perhaps > instantiate > > a business > > object and ask it to perform some service. My point was > that > > in the act of > > performing a service the business object would likely > exhaust more cpu > > cycles/memory than would be expending creating an action > > class instance and > > garbage collecting it. What motivated me to ask this > question was the > > following verbage I found on Martin Fowler's site: > > http://www.martinfowler.com/isa/frontController.html, > regarding front > > controller command classes and thread-safety: > > > > "Since you create new command object with each request, you > > don't have to > > worry about making the command classes thread safe. This can > avoid the > > headaches of multi-threaded programming. You do have to make > > sure that you > > don't share any other objects, such as the model objects." > > > > > Also, if you are creating an Action for every request, > > there isn't much > > > point in having instance variables that might cause > serialization > > issues, > > > so why have more than one instance? > > > > In principle I agree. However, again in reality it many > > times is the case > > that developers don't consider thread safety issues as > closely as they > > should. This reality coupled with Martin's comments above > > made me curious > > as to what maintaining a single instance of commands buys > you. > > > > Again, not saying maintaining a single instance of actions > is > > not good or > > perhaps the best approach, just looking to understand. > > > > Thanks > > Steve > > > > > > > > > > > > > > "Hal Deadman" > > > > <hal.deadman@T > > > > allan.com> > > > > > > > > 05/13/2002 > > > > 08:22 AM To: "'Struts Developers > > List'" <[EMAIL PROTECTED]> > > Please respond cc: > > > > to "Struts > > > > Developers > > > > List" > > > > Subject: RE: > > Scalability question > > > > > > > > > > > > Caterpillar: Confidential Green Retain Until: > 06/12/2002 > > Retention Category: > G90 - > > Information and > Reports > > > > > > > > > > Action clases aren't supposed to have any kind of serious > > business process. > > You should keep your business objects "Struts-free". That's > > why you don't > > pass ActionForms directly to EJBs or business components. > > Struts needs to > > stop at the view-controller because the model should not > depend on the > > view. > > > > Also, if you are creating an Action for every request, there > > isn't much > > point in having instance variables that might cause > > serialization issues, > > so why have more than one instance? If you are saying that > > there should be > > one Action instance per session then I would argue that you > > should manage > > your use of the session seperately, it's not in the Action > > classes' domain. > > > > Hal > > > > > -----Original Message----- > > > From: Steven D. Monday [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, May 13, 2002 8:57 AM > > > To: Struts Developers List > > > Subject: RE: Scalability question > > > > > > > > > > > > In the paragraph below Craig mentioned that the "same one > > > (action instance) > > > is reused continuously". I'm curious as to the rationale > behind > > > maintaining a single instance of each action class, > > > especially given that > > > it does introduce the requirement (unfortunately not > always > > > understood by > > > developers) that actions be written in a reentrant > fashion. > > > I'm assuming > > > that it was perhaps a performance optimization? However, > it > > > seems that if > > > an action class invokes any kind of serious business > > process that the > > > time/resources expended creating (even reflectively) and > > destroying an > > > action instance would pale compared to time/resources > > expended by the > === message truncated === __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
