[cgiapp] need a fresh WebApp instance with every request ?

Ron Savage ron at savage.net.au
Wed Nov 30 18:27:26 EST 2011


Hi Matthias

On Wed, 2011-11-30 at 02:43 +0100, Matthias Ferdinand wrote:
> On Wed, Nov 30, 2011 at 11:01:04AM +1100, Ron Savage wrote:
> > Hi Matthias
> > 
> > On Sun, 2011-11-27 at 17:24 +0100, Matthias Ferdinand wrote:
> > 
> > > I could not find in CGI::Application's docs if a single instance object
> > > is capable of handling multiple requests (i.e. has run() invoked several
> > > times) or not.
> [...]
> 
> > So, don't do it that way. Just accept that you need a new instance obj
> > each time.
> 
> Hi Ron, thanks for answering.
> 
> I can modify my server script accordingly, and if my app at some point
> needs more caching urgently, I could create a different per-process
> object that persists over multiple requests and hand its ref to the
> single-request WebApp instances.

I suggest you forget caching. It adds complexity, and you'd need to
benchmark code to demonstrate where exactly the problem is - if any! -
before deciding caching was the solution.

I used CGI::App (and CGI::App::Dispatch) for years without needing to
think about it.

> It is just that it is not mentioned in the docs, and I think it should
> be. Could have saved me a day or two of debugging.

I suggest you log a request ticket for CGI::App for this.

> And definitely the pod of CGI::Application::Server should be fixed. It
> uses the WebApp object in this multi-request way, and I copied my server
> script from there.

And another request ticket for CGI::App::Server likewise.

That would give those authors an opportunity to explain why I'm wrong,
if I am :-).

> OTOH, finding all the per-request variables should not be too hard.  As
> for the plugins, that would indeed amount to a new design constraint.
> CGI::Application could e.g. offer a new anon hash where plugins can move
> their per-request variables to, like $self->{__CAP_PER_REQUEST}, and set
> it to {} in run(). Instant cleanup with every new request :-)

But that requires all plugin authors to agree, and to find the time, and
to write the code, and to test it, and to release it.

Then there'd be the problem of users of those plugins perhaps using
undocumented access to the internals of those modules, whose code would
fail with the new versions.

Nope - not going to happen - forget it!

> > And for a persistent environment, I'd strongly suggest you switch to
> > Plack.
> Will sure look into this, thanks.

Good thinking.

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622



More information about the cgiapp mailing list