Paul, I am very interested in your approach. Could you provide me with some samples? I would be very appreciative.
Regards, Travis On 4/3/06, Paul Russell <[EMAIL PROTECTED]> wrote: > > Travis, > > On 3 Apr 2006, at 22:36, Travis Romney wrote: > > I have a fairly large application that I am maintaining right now. > > I am running over 100 web apps on my server, and It can > > cause some serious memory issues. With tapestry version 3.0.x > > I was able to tweak the code by making some of the caches static > > so that the component specifications and other resources could > > be shared across web apps. > > [...] > > I am currently having the same issues with tapestry 4.0. > > The code has changed dramatically since 3.0.x and I'm having > > the same trouble I had with 3.0.x. These web applications > > are completely identical with the exception of pointing to a different > > database. > > [...] > > I am very interested in anybodys opinions and suggestions. > > Suspect this might not be the answer you're looking for, but there is > another approach to this problem that might well turn out to be > significantly /more/ scalable than what you're doing here, if you're > interested. The approach I'm about to describe depends on some > preconditions with respect to the application and architecture you're > using: > > 1) The code of the application is under your control. > 2) The instances really are identical except for the database > connection. > 3) There is no application state extrinsic to an individual request > or session. (i.e. there is no shared in-memory state within the > application as it stands) > 4) You have a unified access point for your database connection/ > hibernate session (I'm assuming your application isn't EJB-based, > given you described it as a webapp) > 5) There is some transparent-to-the-application way (hostname, for > example) to determine which 'partner' the application is currently > executing on behalf of. > > The approach involves leveraging some of the neat bits of Hivemind to > provide a method for isolating specific parts of the application > between partners without having to isolate the whole application. The > approach in three easy steps: > > 1) Define a new hivemind service enables a thread to be > 'blessed' (note: need to use the 'run as' pattern for this) as > running on behalf of a particular 'partner'. Provide an object > provider that enables the current partner to be injected into a service. > 2) Optional: Define a new hivemind service model that partitions > service implementations based on the current 'partner'. > 3) Define a new hivemind service implementing > org.apache.tapestry.services.WebRequestServicerFilter that determines > the 'current' partner from the incoming request, and invokes (1) to > bless the current thread with the relevant partner. > 4) Refactor the application to move the database connection related > code into hivemind services, and either inject the current partner > into the service and enable it to select the correct connection, or > define the service with the 'partner' service model, and manage the > connection pools/sessionfactory at this level. > > As I say, this is a pretty different approach to where you are right > now, and it might not be something you wish to consider at the > moment, but it would potentially allow some fairly serious > scalability without the overheads of having a separate application > per partner. If you're interested, I'm happy to go into more details. > > > Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
