tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Romney" <trom...@gmail.com>
Subject Re: Sharing Tapestry Libraries
Date Mon, 03 Apr 2006 22:39:51 GMT
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 <paul@paulrussell.org> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message