Re: sesion managing
There are many solutions to your problem that are perl specific and some minor twists that are mod_perl specific. You may have better luck using a perl-oriented mailing list for this topic, or read up on how HTTP works and all the various places that you can store session information (query string, path information, the hostname, cookies, etc), and decide how much data you need to save and where you need to save it. If you then decide that the _best_ place to do this requires mod_perl (btw: none of the places I just suggested technically require it) then come back and we can tell you how to accomplish that. On Mon, 2002-12-30 at 04:46, koudjo ametepe wrote: hi everbody , How do you do I developping an intranet project with perl and Mysql . I encounter a problem and still i haven't found a solution .The problem is previously i was using php/mysql ; with the function sesssion_xxx i was able to keep user id through all the pages and store it any time that the user save something in the database . Umfortunately i don't know how to do this with perl , i read some articles on the net about it but i get nothing. Please can you give me some ideas about the session managing in perl/mysql thanks koudjo
Re: Same $dbh under different pids?
On Wed, 2002-10-30 at 14:52, Perrin Harkins wrote:
> harm wrote:
>
> >On Wed, Oct 30, 2002 at 06:05:51PM +0800, Philippe M. Chiasson wrote:
> >
> >
> >>For the same reason that running this:
> >>$> perl -e'fork; { $foo = {}; print "$$:$foo\n"}'
> >>1984:HASH(0x804c00c)
> >>1987:HASH(0x804c00c)
> >>
> >>produces this for me, every single time I run this program
> >>
> >>You are assuming that if (0x804c00c) is equal in different processes,
> >>they must be pointers(or references, or handles) to the same thing. And
> >>it is not the case ;-)
> >>
>
> Wait, ins't it the case? That number is supposed to be the location in
> memory. It seems like these are all pointing to the same hash. I can't
> explain how that would happen though, based on the code shown here.
You're confusing virtual memory with physical memory. Given an SMP
system where pid 1984 and 1987 can both actually run at the same time
(thus ensuring neither is "swapped out") address 0x804c00c actually
occupies two completely distinct blocks of physical memory.
$ perl -e '$foo = {}; fork; print "$$:$foo\n";'
18161:HASH(0x80fd254)
18162:HASH(0x80fd254)
$ perl -e 'fork; $foo = {}; print "$$:$foo\n";'
18163:HASH(0x80fd254)
18164:HASH(0x80fd254)
The effects are entirely expected. Perl takes up so much memory, and
that amount doesn't increase or decrease unless I recompile perl. So the
first allocation for a hash seems bound to occur at the same address in
virtual-memory every single time.
$ perl -e '$foo = {bar => 1};fork;print "$$:$foo" . $foo->{bar} . "\n";'
That works like you'd expect, doesn't it? Now consider this:
#!/usr/bin/perl
$foo = {};
if (fork == 0) {
sleep(1);
} else {
$foo->{bar} = 1;
}
print "$$:$foo:" . $foo->{bar} . "\n";'
All this serves to demonstrate is that the parent cannot modify the
child's memory map. While both exist in the same place in virtual
memory, the values obviously contain different values, and the physical
memory itself is different.
It's difficult to fully appreciate this in Perl... Maybe someone will
make a proper mmap() someday.
very OT: english/german -- was Re: Antwort: Re:[Apache::AuthenNTLM] Performance Probs
> always: When you want it to happen, it doesn't (Does anyone know a good > English word for "Vorführeffekt"?). Sod's Law (British) or Murphy's Law (American English) are pretty close. 1. In any situation, if something can go wrong, it will go wrong. 2. In any situation, even if nothing can go wrong, it will still go wrong. 3. When you haven't planned to get into a situation where Sod's Law could do anything that could possibly bother you in the slightest, Sod's law dictates it will bugger up someone else's day, which will inadvertently ruin your day as well. But I don't think it counts. Sod's Law is more of a joke- a thought game. I don't think there's a good English-y word (or words) for Vorfuhreffekt. The fish says "Demonstration Failure" or "Demonstrating Effect" - neither of which cuts it. It's a good word, and I have heard it suggested that it be adopted into English but we all know that while the English language will admit a word like "Doh" - the contestants on "Wheel Of Fortune" wouldn't ever be able to pronounce it without sounding much like a rhinoceros fornicating with a steel shed. However, Yiddish has several inflection-rules (if you can call them that) that were borrowed into English. Probably because it sounds funny. It's a bit difficult to properly connote this in-type, but we can try: "Well, it _was_ doing it!" And finally, as the field circus says: If it happens again, reinstall.
[MP2] Net::LDAP/Convert::ASN1 and mod_perl 2
I'm using Mod_perl (1.99_07), Apache 2, and using the threaded MPM. I have ithreads installed and most everything works excellently. I am having a problem using Net::LDAP- specifically with $ldh->add() operations. $ldh->search() works fine, $ldh->modify also seems to work. Has anyone else experienced this? Is there a simple solution or fix? Further investigation reveals that the hang occurs within a sysread() in Convert::ASN1::asn_read() [within the IO.pm] I would suspect some interactions between threads/Net::LDAP/Convert:ASN1 -- except it only happens on ->add operations.
