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]
