You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Gunther Birznieks <gu...@extropia.com> on 2000/02/16 11:41:10 UTC
Apache::Session-- how does it protect session data?
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 14:53:12 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 14:53:12 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 14:53:12 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 13:59:26 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 13:59:26 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 13:59:26 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 13:59:26 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 13:59:26 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 13:59:26 MET 2000
>From modperl-return-59-petchema=concept-micro.com@apache.org Wed Feb 16 13:12:35 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id NAA02670
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 13:12:25 +0100
Received: (qmail 24016 invoked by uid 500); 16 Feb 2000 12:11:48 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 24005 invoked from network); 16 Feb 2000 12:11:47 -0000
Date: Wed, 16 Feb 2000 13:11:16 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 13:11:16 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 13:11:16 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 13:11:16 MET 2000
>From modperl-return-58-petchema=concept-micro.com@apache.org Wed Feb 16 12:41:22 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id MAA02125
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 12:40:30 +0100
Received: (qmail 19725 invoked by uid 500); 16 Feb 2000 11:39:50 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 19710 invoked from network); 16 Feb 2000 11:39:50 -0000
Date: Wed, 16 Feb 2000 12:39:09 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 12:23:01 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:23:01 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:23:01 MET 2000
>From root Wed Feb 16 11:51:32 2000
Return-Path: <root>
Received: from (root@localhost)
by deckard.concept-micro.com (8.8.7/jtpda-5.2) id LAA00596
; Wed, 16 Feb 2000 11:51:32 +0100
Date: Wed, 16 Feb 2000 11:51:32 +0100
From: root (root)
Message-Id: <20...@deckard.concept-micro.com>
Subject: [FAX] De _ _ (2 pages)
XFMstatus: 0002
Les informations sont accessibles depuis http://www.workgroup/faxes/cgi/faxbrowser.pl?fax=20000216-1150
>From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Feb 16 12:06:20 2000
Return-Path: <ow...@vger.rutgers.edu>
Received: from nic.funet.fi (nic.funet.fi [193.166.0.145])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with ESMTP id MAA01253
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 12:06:10 +0100
Received: from vger.rutgers.edu ([128.6.190.2]:14968 "EHLO vger.rutgers.edu"
ident: "NO-IDENT-SERVICE[2]" smtp-auth: <none> TLS-CIPHER: <none>)
by nic.funet.fi with ESMTP id <S16260AbQBPLFC>;
Wed, 16 Feb 2000 13:05:02 +0200
Received: by vger.rutgers.edu via listexpand id <S153977AbQBPG4u>;
Wed, 16 Feb 2000 01:56:50 -0500
Received: by vger.rutgers.edu id <S154056AbQBPGwY>;
Wed, 16 Feb 2000 01:52:24 -0500
Received: from app79.hitnet.RWTH-Aachen.DE ([137.226.181.79]:1050 "EHLO
anduin.gondor.com") by vger.rutgers.edu with ESMTP
id <S154136AbQBPGoq>; Wed, 16 Feb 2000 01:44:46 -0500
Received: from moria.gondor.com (moria.gondor.com [194.221.174.61])
by anduin.gondor.com (8.9.3/8.9.3) with ESMTP id LAA07577;
Wed, 16 Feb 2000 11:48:19 +0100
Received: (from jan@localhost)
by moria.gondor.com (8.8.7/8.8.7) id LAA01008;
Wed, 16 Feb 2000 11:48:18 +0100
Date: Wed, 16 Feb 2000 11:48:18 +0100
From: Jan Niehusmann <li...@gondor.com>
To: Tigran Aivazian <ti...@aivazian.fsnet.co.uk>
Cc: Linus Torvalds <to...@transmeta.com>, linux-kernel@vger.rutgers.edu,
hpa@transmeta.com
Subject: Re: [patch-2.3.46-p2] P6 microcode update support
Message-ID: <20...@gondor.com>
Reply-To: jan@gondor.com
References: <Pi...@penguin.transmeta.com> <38...@aivazian.fsnet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38...@aivazian.fsnet.co.uk>; from tigran@aivazian.fsnet.co.uk on Wed, Feb 16, 2000 at 08:01:47AM +0000
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu
X-Orcpt: rfc822;linux-kernel-outgoing-dig
XFMstatus: 0002
On Wed, Feb 16, 2000 at 08:01:47AM +0000, Tigran Aivazian wrote:
> Also, more importantly, Intel manual says "the update must run in the
> early stages of POST and always before L2 cache controllers are
> initialized". I ignored it and it still worked fine.
I don't know much about intel microcode, but perhaps a microcode update
_may_ change cache handling. So it might work with every microcode
update available now (because Intel didn't make any incompatible
changes), but may fail with the next one.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 13:11:16 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 13:11:16 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 13:11:16 MET 2000
>From modperl-return-58-petchema=concept-micro.com@apache.org Wed Feb 16 12:41:22 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id MAA02125
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 12:40:30 +0100
Received: (qmail 19725 invoked by uid 500); 16 Feb 2000 11:39:50 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 19710 invoked from network); 16 Feb 2000 11:39:50 -0000
Date: Wed, 16 Feb 2000 12:39:09 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 12:23:01 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:23:01 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:23:01 MET 2000
>From root Wed Feb 16 11:51:32 2000
Return-Path: <root>
Received: from (root@localhost)
by deckard.concept-micro.com (8.8.7/jtpda-5.2) id LAA00596
; Wed, 16 Feb 2000 11:51:32 +0100
Date: Wed, 16 Feb 2000 11:51:32 +0100
From: root (root)
Message-Id: <20...@deckard.concept-micro.com>
Subject: [FAX] De _ _ (2 pages)
XFMstatus: 0002
Les informations sont accessibles depuis http://www.workgroup/faxes/cgi/faxbrowser.pl?fax=20000216-1150
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 13:11:16 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 13:11:16 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 13:11:16 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 12:23:01 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:23:01 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:23:01 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 12:23:01 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:23:01 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:23:01 MET 2000
>From root Wed Feb 16 11:51:32 2000
Return-Path: <root>
Received: from (root@localhost)
by deckard.concept-micro.com (8.8.7/jtpda-5.2) id LAA00596
; Wed, 16 Feb 2000 11:51:32 +0100
Date: Wed, 16 Feb 2000 11:51:32 +0100
From: root (root)
Message-Id: <20...@deckard.concept-micro.com>
Subject: [FAX] De _ _ (2 pages)
XFMstatus: 0002
Les informations sont accessibles depuis http://www.workgroup/faxes/cgi/faxbrowser.pl?fax=20000216-1150
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 12:06:55 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:06:55 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:06:55 MET 2000
>From modperl-return-53-petchema=concept-micro.com@apache.org Wed Feb 16 11:52:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00614
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:51:54 +0100
Received: (qmail 5485 invoked by uid 500); 16 Feb 2000 10:51:21 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 5473 invoked from network); 16 Feb 2000 10:51:20 -0000
Date: Wed, 16 Feb 2000 11:50:20 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:50:20 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:50:20 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:50:20 MET 2000
>From modperl-return-52-petchema=concept-micro.com@apache.org Wed Feb 16 11:50:19 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00448
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:50:13 +0100
Received: (qmail 3925 invoked by uid 500); 16 Feb 2000 10:49:50 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 3908 invoked from network); 16 Feb 2000 10:49:49 -0000
Date: Wed, 16 Feb 2000 11:48:21 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:48:21 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:48:21 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:48:21 MET 2000
>From modperl-return-51-petchema=concept-micro.com@apache.org Wed Feb 16 11:48:19 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00360
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:48:14 +0100
Received: (qmail 2299 invoked by uid 500); 16 Feb 2000 10:47:51 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 2288 invoked from network); 16 Feb 2000 10:47:50 -0000
Date: Wed, 16 Feb 2000 11:47:17 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:47:17 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:47:17 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:47:17 MET 2000
>From modperl-return-50-petchema=concept-micro.com@apache.org Wed Feb 16 11:47:16 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00331
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:47:12 +0100
Received: (qmail 872 invoked by uid 500); 16 Feb 2000 10:46:52 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 855 invoked from network); 16 Feb 2000 10:46:52 -0000
Date: Wed, 16 Feb 2000 11:46:11 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
>From modperl-return-49-petchema=concept-micro.com@apache.org Wed Feb 16 11:46:10 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00292
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:46:05 +0100
Received: (qmail 99293 invoked by uid 500); 16 Feb 2000 10:45:46 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 99281 invoked from network); 16 Feb 2000 10:45:46 -0000
Date: Wed, 16 Feb 2000 11:45:07 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 12:06:55 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 12:06:55 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 12:06:55 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:50:20 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:50:20 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:50:20 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:50:20 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:50:20 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:50:20 MET 2000
>From modperl-return-52-petchema=concept-micro.com@apache.org Wed Feb 16 11:50:19 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00448
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:50:13 +0100
Received: (qmail 3925 invoked by uid 500); 16 Feb 2000 10:49:50 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 3908 invoked from network); 16 Feb 2000 10:49:49 -0000
Date: Wed, 16 Feb 2000 11:48:21 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:48:21 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:48:21 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:48:21 MET 2000
>From modperl-return-51-petchema=concept-micro.com@apache.org Wed Feb 16 11:48:19 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00360
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:48:14 +0100
Received: (qmail 2299 invoked by uid 500); 16 Feb 2000 10:47:51 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 2288 invoked from network); 16 Feb 2000 10:47:50 -0000
Date: Wed, 16 Feb 2000 11:47:17 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:47:17 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:47:17 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:47:17 MET 2000
>From modperl-return-50-petchema=concept-micro.com@apache.org Wed Feb 16 11:47:16 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00331
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:47:12 +0100
Received: (qmail 872 invoked by uid 500); 16 Feb 2000 10:46:52 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 855 invoked from network); 16 Feb 2000 10:46:52 -0000
Date: Wed, 16 Feb 2000 11:46:11 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
>From modperl-return-49-petchema=concept-micro.com@apache.org Wed Feb 16 11:46:10 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00292
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:46:05 +0100
Received: (qmail 99293 invoked by uid 500); 16 Feb 2000 10:45:46 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 99281 invoked from network); 16 Feb 2000 10:45:46 -0000
Date: Wed, 16 Feb 2000 11:45:07 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:48:21 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:48:21 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:48:21 MET 2000
>From modperl-return-51-petchema=concept-micro.com@apache.org Wed Feb 16 11:48:19 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00360
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:48:14 +0100
Received: (qmail 2299 invoked by uid 500); 16 Feb 2000 10:47:51 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 2288 invoked from network); 16 Feb 2000 10:47:50 -0000
Date: Wed, 16 Feb 2000 11:47:17 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:47:17 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:47:17 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:47:17 MET 2000
>From modperl-return-50-petchema=concept-micro.com@apache.org Wed Feb 16 11:47:16 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00331
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:47:12 +0100
Received: (qmail 872 invoked by uid 500); 16 Feb 2000 10:46:52 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 855 invoked from network); 16 Feb 2000 10:46:52 -0000
Date: Wed, 16 Feb 2000 11:46:11 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
>From modperl-return-49-petchema=concept-micro.com@apache.org Wed Feb 16 11:46:10 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00292
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:46:05 +0100
Received: (qmail 99293 invoked by uid 500); 16 Feb 2000 10:45:46 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 99281 invoked from network); 16 Feb 2000 10:45:46 -0000
Date: Wed, 16 Feb 2000 11:45:07 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:48:21 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:48:21 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:48:21 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:47:17 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:47:17 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:47:17 MET 2000
>From modperl-return-50-petchema=concept-micro.com@apache.org Wed Feb 16 11:47:16 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00331
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:47:12 +0100
Received: (qmail 872 invoked by uid 500); 16 Feb 2000 10:46:52 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 855 invoked from network); 16 Feb 2000 10:46:52 -0000
Date: Wed, 16 Feb 2000 11:46:11 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
>From modperl-return-49-petchema=concept-micro.com@apache.org Wed Feb 16 11:46:10 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00292
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:46:05 +0100
Received: (qmail 99293 invoked by uid 500); 16 Feb 2000 10:45:46 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 99281 invoked from network); 16 Feb 2000 10:45:46 -0000
Date: Wed, 16 Feb 2000 11:45:07 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:47:17 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:47:17 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:47:17 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
>From modperl-return-49-petchema=concept-micro.com@apache.org Wed Feb 16 11:46:10 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00292
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:46:05 +0100
Received: (qmail 99293 invoked by uid 500); 16 Feb 2000 10:45:46 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 99281 invoked from network); 16 Feb 2000 10:45:46 -0000
Date: Wed, 16 Feb 2000 11:45:07 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:46:11 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:46:11 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:46:11 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
>From modperl-return-48-petchema=concept-micro.com@apache.org Wed Feb 16 11:45:06 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00244
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:45:01 +0100
Received: (qmail 97427 invoked by uid 500); 16 Feb 2000 10:44:42 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 97416 invoked from network); 16 Feb 2000 10:44:41 -0000
Date: Wed, 16 Feb 2000 11:44:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
To: modperl@apache.org
References: <38...@extropia.com> <20...@deckard.concept-micro.com>
In-Reply-To: <20...@deckard.concept-micro.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:45:07 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:45:07 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:45:07 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:44:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:44:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:44:00 MET 2000
>From modperl-return-47-petchema=concept-micro.com@apache.org Wed Feb 16 11:43:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00186
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:43:56 +0100
Received: (qmail 95942 invoked by uid 500); 16 Feb 2000 10:43:37 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 95930 invoked from network); 16 Feb 2000 10:43:36 -0000
Date: Wed, 16 Feb 2000 11:42:00 +0100
Message-Id: <20...@deckard.concept-micro.com>
To: modperl@apache.org
References: <38...@extropia.com>
In-Reply-To: <38...@extropia.com>
X-Loop: MAILER-DAEMON@deckard
From: MAILER-DAEMON@concept-micro.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
Sender: petchema@concept-micro.com
XFMstatus: 0002
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
Returned mail: User unknown
Posted by Mail Delivery Subsystem <MA...@concept-micro.com>.
The original message was received at Wed Feb 16 11:42:00 MET 2000
from modperl@apache.org
----- The following addresses had permanent fatal errors -----
petchema@deckard
----- Transcript of session follows -----
... while talking to deckard.:
>>> RCPT To:<pe...@deckard>
<<< 550 Bad recipient
550 petchema@deckard... User unknown
Reporting-MTA: dns; deckard
Arrival-Date: Wed Feb 16 11:42:00 MET 2000
Final-Recipient: RFC822; petchema@deckard
Action: failed
Status: 5.1.1
Diagnostic-Code: SMTP; 550 Bad recipient
Last-Attempt-Date: Wed Feb 16 11:42:00 MET 2000
>From modperl-return-46-petchema=concept-micro.com@apache.org Wed Feb 16 11:41:59 2000
Return-Path: <mo...@apache.org>
Received: from locus.apache.org (locus.apache.org [63.211.145.10])
by deckard.concept-micro.com (8.8.7/jtpda-5.2) with SMTP id LAA00148
for <pe...@concept-micro.com>; Wed, 16 Feb 2000 11:41:54 +0100
Received: (qmail 94464 invoked by uid 500); 16 Feb 2000 10:41:35 -0000
Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
Reply-To: modperl@apache.org
list-help: <ma...@apache.org>
list-unsubscribe: <ma...@apache.org>
list-post: <ma...@apache.org>
Delivered-To: mailing list modperl@apache.org
Received: (qmail 94453 invoked from network); 16 Feb 2000 10:41:35 -0000
Message-ID: <38...@extropia.com>
Date: Wed, 16 Feb 2000 10:41:10 +0000
From: Gunther Birznieks <gu...@extropia.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: modperl@apache.org
Subject: Apache::Session-- how does it protect session data?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XFMstatus: 0002
I am trying to understand the locking model that is used to protect an
Apache::Session from being trampled by multiple processes. The
documentation talks about implementing it in a way that people would
expect.
Unfortunately, when I think about it, there are quite a few ways I could
expect locking to work to make sure the session data is saved.
It looks to me like the default is
1) Read lock upon loading an existing session
2) Exclusive lock upon creating a session from scratch
3) Exclusive lock upon writing data (not upon storage of data in the
session hash!)
4) Release locks only upon destruction of the session object
It's very possible I could be wrong, but this model strikes me as
promoting deadlock and not preventing session corruption.
Let's consider a couple possible scenarios:
1. Let's suppose that two processes (1 and 2) both want to modify a
variable in the session. For arguement's sake, let's say that one
process is modifying an "age" key while the other one is modifying a
"firstname" key.
Let's also assume the session was previously created.
Thus, process 1 loads a session. Obtains a read (non exclusive) lock.
Process 1 modifies the age value. This is done to a memory-resident
cache so no exclusive lock is obtained yet as no write is performed to
the data store.
Process 2 loads the same session. Perhaps the result of a submission
from a different frame of a web app or in a different browser window.
Obtains a read (non exclusive) lock.
Process 2 modifies the "firstname" key/value. Again, this is done to
memory-resident cache (at least this is how I read Apache::Session).
Now, let's assume process 1 (running at about the same time)... gains
control of CPU and the program completes. At this point the session
object goes out of scope.
When Process 1's session object goes out of scope, it attempts to write
the session data that it could not write previously. Before doing this,
however, it must obtain an exclusive lock.
But it can't get an exclusive lock as Process 2 still has a read only
lock on the same session.
So eventually process 1 blocks until process 2 gains CPU time again.
Process 2 then ends up exiting and the destruction of Process 2's CGI
object demands that, it too, get an exclusive lock on the session to
write the firstname data out to the persistent data store.
Unfortunately process 2 must wait for process 1 to release the read lock
it has.
Deadlock. Process 1 wants process 2 to release its read only lock and
process 2 wants process 1 to release its read only lock.
The other alternative I see is that the locks would be freed after a
timeout period.. but if this is the case, then one of the process'es
acts of writing the session data to the data store will overwrite the
other's. The session file will not be corrupted because the entire write
operation will be surrounded by an exclusive lock, but the data will be
"logically" corrupted because the application author will have an
applicatin state he did not expect.
In conclusion, the locking workflow in Apache::Session confuses me. I
suspect people haven't run into this problem before because most people
do not share sessions among many different apps and the likelihood that
two scripts will be writing the same session 's data to disk at the same
time is extremely low.
However, I imagine the locking was put in place to prevent data
corruption in these extreme cases... so if this is the case, I am
wondering if it is really does work in these cases?
I have tried going through the Apache::Session logic myself to figure
this out, and I might be missing some piece of the puzzle... Hopefully
Jeffrey or someone else can shed some light on this for me?
At the very minimum, I would expect step 3 from above (the act of
storing any one data value in the session) to end up causing the session
to obtain an exclusive lock. I believe this would prevent the deadlock
scenario I outlined above. The problem with this mechanism is that
concurrency goes way done for an application that might require reading
the session data into multiple processes at hte same time. For example,
if an app uses frames, session data that might be read in other frames
at the same time will definately force those framed scripts to wait.
This will cause the frames to look like they are loading in order
instead of all at once... a bit of an ugly sight.
Please no comments on the merits (or lack thereof) of using frames.
:)... I am merely focusing on why the locking logic exists in
Apache::Session the way it does, and in what cases I am not sure whether
the locking will actually work as intended.
Thanks,
Gunther