On 12 Jul 2010, at 15:34, Derek Wueppelmann wrote:
On Sat, 2010-07-10 at 13:37 -0400, Alejandro Imass wrote:
If in a Catalyst::Component, say an extension of Catalyst::Model, the
attributes of my instance are also per-request. In other words if I
do
$self->yuca($c->stash->{yuca}) in ACCEPT_CONTEXT and return $self,
will $self->yuca in the Model _instance_ in a separate memory space
for this request?
No.
Each process is in a separate memory space if you're using FCGI or
mod_perl or something, but it's not entirely certain (if you use
Catalyst::Engine::PSGI and Corona (for example) then multiple requests
can be in-flight and sharing the same logicial memory space
application (they just have different instances of the request context).
However doing what you suggest above will work for FCGI/mod_perl (or
generally anything forked), although it's a bit icky - the instance of
your Model lasts forever, and so bashing some of the instance data in
each request works..
I would however you return an entirely new instance constructed in
ACCEPT_CONTEXT, or use Catalyst::Component::InstancePerContext if
you'd like the instance you build to be scoped to the request.
I would suspect that a Catalyst::Controller instance
is paired with a single Model instance for a specific request....
No.
Nothing implies that controllers own models - they're entirely
independent (and there can be many controllers and many models
involved in processing a request).
but
I'm afraid that being an _instance_ instead of a class, the
attributes
may get overriden by a second request that could be running in a
parallel process or thread, say in mod_perl running on Apache prefork
or worker (threads). Then again, I guess I'm answering myself as one
request will run in one process or thread and the data segment is
protected by the underlying OS, so I see no way a second request can
override the attributes of a model instance.
But you're correct here.
From my understanding when you make a request to the system all the
variable and objects are localized to the scope of that request.
Incorrect. If you write into a global variable in request 1, then
request 2 (which happens in _that process_) will be able to see the
data.
So
making multiple requests open multiple scopes and the data does not
mix
between them. If you require data to survive past a single request
this
is where the session object comes in. You can then store data and
objects that are required to survive past a single request here,
however
this are specific for the session so don't mix with other requests
that
are not related to the session.
But this is kinda right - you can't be certain that you'll get the
same application server process twice in a row, so you need to persist
data in some way that ensures whatever app server process answers it
can find the data..
Cheers
t0m
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
