Hello all and thanks a lot for the responses, it makes thinks
at least a bit clearer ;-)

To answer about my configuration, I have the following:

PerlSetEnv EMBPERL_SESSION_CLASSES "Postgres Semaphore Base64"
PerlSetEnv EMBPERL_SESSION_ARGS
"DataSource=dbi:Pg(AutoCommit=>1):dbname=sessions UserName=ausername"

and on the logs I have the following at server startup:

[Thu Apr  5 09:38:48 2001] [notice] Apache < mod_perl/1.25 etc... >
configured -- resuming normal operations

and this at the command prompt:

[14180]SES:  Embperl Session management enabled (>= 1.50)
/usr/local/apache/bin/apachectl start: httpd started

So I thaught everything was ok for Session management.

Actually this part (Embperl Configuration) then would refer to the previous
message I posted here (ie.: 'Embperl & Postgres & Session Management'):
actually
that was sorted out (or so I thaught, unless you tell me otherwise): simply
the
Postgres doent like the 'Storable' default and had to use 'Base64' as well
as
remove some IPC stuffs hanging there from previous (default 'Storable')
crashes.

Anyway, here is all the configuration directives I have placed in my
httpd.conf
concerning Embperl:

# -- Embperl Configuration.

PerlSetEnv EMBPERL_SESSION_CLASSES "Postgres Semaphore Base64"
PerlSetEnv EMBPERL_SESSION_ARGS
"DataSource=dbi:Pg(AutoCommit=>1):dbname=sessions UserName=ausername"

PerlModule HTML::Embperl;

<Files ~ "\.(html|epl)$">
  SetHandler  perl-script
  PerlHandler HTML::Embperl
  Options     ExecCGI
</files>

# --.

This should be ok.. ?

This morning I tried to do some simple things like restarting postgres and
apache,
deleting the cookies (on the browser as well as in the postgres session
tables).
Or cheked that the session table (in Postgres) was ok (ie. fields types,
writable
, etc., by the user used by apache - anyway this was ok allready since I
could see
that table being filled up), trying out from different browsers..

All whith the same result: one.html is allways fine
                           two.html allways crashes
                           tree.html allways gives the proper answer (ie.:
"Hello"
                                     when a previous call to one.html has
been done
                                     of course, otherwise empty)

Other software using session management has been tested as well, and works
perfectly
fine as long as they dont use this "second level hash" (or that lukilly it
initializes
some simple $udat{simple} to something before.

Versions are:

 - Apache 1.3.19
 - Embperl 1.3.1
 - ModPerl 1.25
 - Postgresql 7.0.3
 - Apache::Session 1.53

Stéphane

PS.: and one last thing:
if i have a file with only:

  [- $udat{some}{thing} = "1" -]

it crashes (undefined HASH..), but if I use "the trick":

  [- $udat{whatever} = "whatever" -]
  [- $udat{some}{thing} = "1"     -]

then it doesnt (tried it many times and allways with the same result).


-----Original Message-----
From: Gerald Richter [mailto:[EMAIL PROTECTED]]
Sent: Donnerstag, 5. April 2001 07:23
To: [EMAIL PROTECTED]
Cc: Stéphane Peiry
Subject: Re: $udat initialisation


>Changes in a hash (or any other list-type) in %udat are not
>saved because mod_perl (I think it was mod_perl here, not
>Embperl) does not see the change.

It's Apache::Session

> I suppose it only checks values
>directly in %udat and therefore sees the same reference to your
>anonymous hashtable regardless if you changed something there or
>not.

That would be true if you change anything in the "second level hash", but
the code makes a assignment to %udat{some}, which is enough to trigger a
saving in Apache::Session

> %udat is only saved when something on the first level
>changes.

Yes

> A workaround for your problem would be to do a
>$udat{dummy}++ after any statement like
>$udat{some}{thing}="Hello".

Yes

>I don't like the behaviour either but when I asked a long time
>ago I was told that it's not that easy to change and that this is
>just the way it is for the moment.


It's just a question of performance. Apache::Session directly get noticed
when anything on the first level changes (because of the tied hash
implementation), but it don't sees any changes on the second etc. level. So
it would have to save the original hash and compare the new hash to that old
one, to find any differences.

> Anyway, if I write a third file 'three.html' wich contains
> just a line more than the 'two.html':
>
> [- $udat{blahblah} = "blahblah" -]
> [+ $udat{some}{thing} +]
>
> then it answers appropriatly "Hello" wich is what I wanted in the first
> place....

>I suppose the request for three.html was answered by the same
>Apache child as one.html, which still had the values somewhere
>and therefore could return them to you.


Yes, that seems to be the case, which leads to the assumtion, that no
session handling at all takes places...

What are your setung of EMBPERL_SESSION_CLASSES and EMBPERL_SESSION_ARGS ?

If both are configurated correctly you should see a message like "Embperl
Session Management enabled" at server startup, do you ?

Gerald

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to