Hi, I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean: package App.pm my $var; // Initialize $var; ..... Route1 => sub { // Modify $var ... } Route2 => sub { // Use $var ... } I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var. Can someone more experienced than I, see if I am doing something obviously incorrect? Thank you Regards.
Don't you want to use sessions to do these sort of things ? On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean:
package App.pm
my $var;
// Initialize $var; .....
Route1 => sub {
// Modify $var ... }
Route2 => sub {
// Use $var ... }
I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
Can someone more experienced than I, see if I am doing something obviously incorrect?
Thank you
Regards.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff. But if there was an error in my logic, I would certainly consider using sessions Thanks On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <dkrotkine@gmail.com>wrote:
Don't you want to use sessions to do these sort of things ?
On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean:
package App.pm
my $var;
// Initialize $var; .....
Route1 => sub {
// Modify $var ... }
Route2 => sub {
// Use $var ... }
I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
Can someone more experienced than I, see if I am doing something obviously incorrect?
Thank you
Regards.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On 24/01/12 19:19, Gurunandan Bhat wrote:
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff.
I do not look to Dancer code for some time, but I almost sure that vars are not preserved across requests. So, the solution would be to declare your own global hash table for keep that information. Cheers ambs
But if there was an error in my logic, I would certainly consider using sessions
Thanks
On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <dkrotkine@gmail.com <mailto:dkrotkine@gmail.com>> wrote:
Don't you want to use sessions to do these sort of things ?
On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com <mailto:gbhat@pobox.com>> wrote: > Hi, > > I was wondering about the issues using a shared variable in a single App.pm > file. Here is what I mean: > > package App.pm > > my $var; > > // Initialize $var; > ..... > > Route1 => sub { > > // Modify $var > ... > } > > Route2 => sub { > > // Use $var > ... > } > > I first call Route1 then when I call Route 2, I expect that I will have the > modified value (by Route 1) of $var in route 2. Unfortunately I get an > undefined value for $var. > > Can someone more experienced than I, see if I am doing something obviously > incorrect? > > Thank you > > Regards. > > > _______________________________________________ > Dancer-users mailing list > Dancer-users@perldancer.org <mailto:Dancer-users@perldancer.org> > http://www.backup-manager.org/cgi-bin/listinfo/dancer-users >
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Response embedded..... On Wed, Jan 25, 2012 at 12:51 AM, ambs <ambs+dancer@perl-hackers.net> wrote:
On 24/01/12 19:19, Gurunandan Bhat wrote:
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff.
I do not look to Dancer code for some time, but I almost sure that vars are not preserved across requests.
So, the solution would be to declare your own global hash table for keep that information.
Indeed, I believe $var is a such a hash table. I have a single App.pm and in that circumstance, $var is available to all route handlers. Is my understanding incorrect? Regards
Cheers ambs
But if there was an error in my logic, I would certainly consider using sessions
Thanks
On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <dkrotkine@gmail.com <mailto:dkrotkine@gmail.com>> wrote:
Don't you want to use sessions to do these sort of things ?
On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com <mailto:gbhat@pobox.com>> wrote: > Hi, > > I was wondering about the issues using a shared variable in a single App.pm > file. Here is what I mean: > > package App.pm > > my $var; > > // Initialize $var; > ..... > > Route1 => sub { > > // Modify $var > ... > } > > Route2 => sub { > > // Use $var > ... > } > > I first call Route1 then when I call Route 2, I expect that I will have the > modified value (by Route 1) of $var in route 2. Unfortunately I get an > undefined value for $var. > > Can someone more experienced than I, see if I am doing something obviously > incorrect? > > Thank you > > Regards. > > > ______________________________**_________________ > Dancer-users mailing list > Dancer-users@perldancer.org <mailto:Dancer-users@**perldancer.org<Dancer-users@perldancer.org>
>
______________________________**_________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/**cgi-bin/listinfo/dancer-users<http://www.backup-manager.org/cgi-bin/listinfo/dancer-users>
______________________________**_________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/**cgi-bin/listinfo/dancer-users<http://www.backup-manager.org/cgi-bin/listinfo/dancer-users>
Ah right, I see, Well, I'm not an expert at ll in these matters, so I may be totally wrong, but I suppose that it depends on how your application is deployed. If it's deployed in a way where you have multiple processes answering to requests, then the state of the variables can't be saved. There is the 'vars' function to store a state variable between requests. On 24 January 2012 20:19, Gurunandan Bhat <gbhat@pobox.com> wrote:
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff.
But if there was an error in my logic, I would certainly consider using sessions
Thanks
On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <dkrotkine@gmail.com> wrote:
Don't you want to use sessions to do these sort of things ?
On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean:
package App.pm
my $var;
// Initialize $var; .....
Route1 => sub {
// Modify $var ... }
Route2 => sub {
// Use $var ... }
I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
Can someone more experienced than I, see if I am doing something obviously incorrect?
Thank you
Regards.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Thanks Damien. I see now that vars is the best way to go. Regards Gurunandan On Wed, Jan 25, 2012 at 12:54 AM, damien krotkine <dkrotkine@gmail.com>wrote:
Ah right, I see,
Well, I'm not an expert at ll in these matters, so I may be totally wrong, but I suppose that it depends on how your application is deployed. If it's deployed in a way where you have multiple processes answering to requests, then the state of the variables can't be saved.
There is the 'vars' function to store a state variable between requests.
On 24 January 2012 20:19, Gurunandan Bhat <gbhat@pobox.com> wrote:
I would have used sessions if these shared variables typically represented "client states". Unfortunately these variables describe the state of the server (its filesystem for example) and I believe that they are best implemented insulated from sessions which are more suited to client-side stuff.
But if there was an error in my logic, I would certainly consider using sessions
Thanks
On Wed, Jan 25, 2012 at 12:44 AM, damien krotkine <dkrotkine@gmail.com> wrote:
Don't you want to use sessions to do these sort of things ?
On 24 January 2012 20:07, Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean:
package App.pm
my $var;
// Initialize $var; .....
Route1 => sub {
// Modify $var ... }
Route2 => sub {
// Use $var ... }
I first call Route1 then when I call Route 2, I expect that I will
have
the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
Can someone more experienced than I, see if I am doing something obviously incorrect?
Thank you
Regards.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Wed, Jan 25, 2012 at 12:54 AM, damien krotkine <dkrotkine@gmail.com> wrote:
There is the 'vars' function to store a state variable between requests.
On Tue, Jan 24, 2012 at 8:54 PM, Gurunandan Bhat <gbhat@pobox.com> wrote:
Thanks Damien. I see now that vars is the best way to go.
I'm certainly not as aware of Dancer internals as Damien, but I would think that this is not the way to go actually. It is my understanding that the "vars" mechanism more or less boils down to what failed for you, and that there is absolutely no effort to synchronize the vars across multiple processes. I think David got it right: You should use the 'vars' keyword if you need to share stuff between a
single request, and use sessions (or e.g. memcached) to maintain state between requests.
A shared data source - database, memcached, whatever - seems to be the right choice to save your server-side state. Cheers, Flavio.
Ah yes, you guys are right, I wrongly wrote "between requests", where it should have been "between routes" :) On 25 January 2012 00:37, Flavio Poletti <polettix@gmail.com> wrote:
On Wed, Jan 25, 2012 at 12:54 AM, damien krotkine <dkrotkine@gmail.com> wrote:
There is the 'vars' function to store a state variable between requests.
On Tue, Jan 24, 2012 at 8:54 PM, Gurunandan Bhat <gbhat@pobox.com> wrote:
Thanks Damien. I see now that vars is the best way to go.
I'm certainly not as aware of Dancer internals as Damien, but I would think that this is not the way to go actually. It is my understanding that the "vars" mechanism more or less boils down to what failed for you, and that there is absolutely no effort to synchronize the vars across multiple processes.
I think David got it right:
You should use the 'vars' keyword if you need to share stuff between a single request, and use sessions (or e.g. memcached) to maintain state between requests.
A shared data source - database, memcached, whatever - seems to be the right choice to save your server-side state.
Cheers,
Flavio.
On Wed, Jan 25, 2012 at 5:07 AM, Flavio Poletti <polettix@gmail.com> wrote:
On Wed, Jan 25, 2012 at 12:54 AM, damien krotkine <dkrotkine@gmail.com> wrote:
There is the 'vars' function to store a state variable between requests.
On Tue, Jan 24, 2012 at 8:54 PM, Gurunandan Bhat <gbhat@pobox.com> wrote:
Thanks Damien. I see now that vars is the best way to go.
I'm certainly not as aware of Dancer internals as Damien, but I would think that this is not the way to go actually. It is my understanding that the "vars" mechanism more or less boils down to what failed for you, and that there is absolutely no effort to synchronize the vars across multiple processes.
I think David got it right:
You should use the 'vars' keyword if you need to share stuff between a
single request, and use sessions (or e.g. memcached) to maintain state between requests.
A shared data source - database, memcached, whatever - seems to be the right choice to save your server-side state.
Cheers,
Flavio.
Thanks. I used simple server side session and it all works now. The data is too small (a few keys into a larger data structure) to use a database or memcache. Regards
On Wed, 25 Jan 2012 00:37:12 +0530 Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean: [...] I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
That's a bad idea because, if you're running in anything other than standalone mode, the process which receives the second request is not necessarily the same one which handled the first request. You should use the 'vars' keyword if you need to share stuff between a single request, and use sessions (or e.g. memcached) to maintain state between requests. Even if you're only planning to run a standalone single-process app now, this design choice would likely bite you in the ass later, when you find you want to run under Starman or similar for performance.
Thanks David. I get it now. I did know the key fact that "...the process which receives the second request is not necessarily the same one which handled the first request..." Thanks for explaining this clearly. Regards Gurunandan On Wed, Jan 25, 2012 at 12:52 AM, David Precious <davidp@preshweb.co.uk>wrote:
On Wed, 25 Jan 2012 00:37:12 +0530 Gurunandan Bhat <gbhat@pobox.com> wrote:
Hi,
I was wondering about the issues using a shared variable in a single App.pm file. Here is what I mean: [...] I first call Route1 then when I call Route 2, I expect that I will have the modified value (by Route 1) of $var in route 2. Unfortunately I get an undefined value for $var.
That's a bad idea because, if you're running in anything other than standalone mode, the process which receives the second request is not necessarily the same one which handled the first request.
You should use the 'vars' keyword if you need to share stuff between a single request, and use sessions (or e.g. memcached) to maintain state between requests.
Even if you're only planning to run a standalone single-process app now, this design choice would likely bite you in the ass later, when you find you want to run under Starman or similar for performance.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (5)
-
ambs -
damien krotkine -
David Precious -
Flavio Poletti -
Gurunandan Bhat