Re: (Sloppy correction) Re: session management with database: optimal parameters in php.ini

phicarre schreef:
On 4 mar, 18:34, phicarre <bertaudm...@xxxxxxxxx> wrote:
On 4 mar, 16:51, Erwin Moller



<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
phicarre schreef:
On 4 mar, 13:30, Erwin Moller
<Since_humans_read_this_I_am_spammed_too_m...@xxxxxxxxxxxxxxxx> wrote:
Erwin Moller schreef:
Hi,
It is clearly a long time ago I used frames. ;-)
This is wrong:
2) in frametest.html you simply put:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd";>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<FRAMESET rows="5%">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
... and 17 more...
</FRAMESET>
</HTML>
This is better:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd";>
<HTML>
<HEAD>
<TITLE>concurrency test</TITLE>
</HEAD>
<FRAMESET
rows="5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%,5%">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
<FRAME src="phpsessiontest.php">
</FRAMESET>
</HTML>
Regards,
Erwin Moller
PS: I didn't test any of my posted code at all. I wrote it all on top of
my head, so you might find more sloppiness.
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
Does your suggested link (adodb ...) "conform" to your advices ?
Propably yes, but I never used their db session management myself.
But their package adodb is of good quality. I have been using it for years.
And that db sessionstorage package is made by the same crew, so I expect
it to be allright.
But you can simply check it yourself with the 20 frames. :-)
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
My module doesn't pass your suggested test !!!
The result is: 2 3 3 4 4 5 5 6 7 7 8 9 10 11 12 13 14 15 16 17

I see two possibilities:
-1- to lock/unlock into open/close
-2- to lock/unlock the row of the session

-1- the equivalent of session_start() in the handler is open read
write close
with one global variable set to 1 if 0 in open and to 0 if 1 in close
but I don't know if the ORWC sequence is ALWAYS performed.

Hi,

Simply check it.
Try the following:
Add a function to your sessionlogic, eg:
function writeToLog($comment){
// Open your logfile, and append to the end $comment
}

Now, in each of your sessionfunctions, you can simply call writeToLog() and later inspect.
That way you'll be deadsure in which order they are called.
You'll need such a function anyway to debug since you cannot reach the output send to the browser from some of the sessionfunctions.




-2- with a transaction, write lock the row during the read, then
update row and commit the transaction.
but I believe that we cannot lock one row in mySQL ?
and I am afraid by the deadlocks ...

What do you think about that ? other solution ?


I block in the read, with a rowlock indeed.

But the code I developed is for MS SQL Server and Postgres.
I avoid MySQL since I consider it an inferior db. :-/
So I cannot help there.


--> Alternatively: If you are not afraid of raceconditions from the same client, simply do it without my concurrencytest (20 frames test).

Remember that problems only arrise if the SAME USER gives you many requests at the same time for pages that use session.
If you think this is not going to happen, or if you are happy with a buggy situation once in a while, simply forget about my test and build it straightforward.

A simple approach:
1) Make a table with:
- the sessionid as PK,
- sessiondata (TEXT),
- session_lock CHAR(1) (Y/N)
- lastaccessdate (datetime) <-- for garbagecollection purposes

2) In session_read test if the session_lock='N'
A) If not , set it to 'Y',
read the session,
update lastaccessdate,
And later in session_write set the session_lock='N'

B) If yes: let the routine sleep for a short amount of time (eg 0.1 sec) and retry


That approach is reasonably, but can in princicple be broken by concurrency in step 2A).
eg: The application tests if session_lock='N', then another PHP script does the same, then script1 goes one in a state that the session is free, and so does script2.

While this seldom happens, the only real way to avoid this is using locking (on rowlevel).

So my advise to you: Make up your mind. :-)
Do you REALLY need the robustness that avoids the concurrent requests? Or will this seldom or never happen?
If your application delivers only 1 page at a time, I cannot think of a scenario where you get in trouble with my above suggestion (A simple approach).
The only thing that will break that approach is a situation as in my framesexample, because your sessionlogic will set session_lock='Y' very quickly, and all other requests are blocked then untill you release it in session_write().
Only requests that arrive at the same time can get you in trpouble, and you really need frames or something for that.

Hope this helps.

Good luck.

Reagrds,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
.

Relevant Pages

  • Re: (Sloppy correction) Re: session management with database: optimal parameters in php.ini
    ... <HEAD> ... make it so simple that there are obviously no deficiencies, ... but I never used their db session management myself. ... But you can simply check it yourself with the 20 frames. ...
    (alt.php)
  • Re: (Sloppy correction) Re: session management with database: optimal parameters in php.ini
    ... make it so simple that there are obviously no deficiencies, ... but I never used their db session management myself. ... But you can simply check it yourself with the 20 frames. ... I avoid MySQL since I consider it an inferior db. ...
    (alt.php)
  • Re: (Sloppy correction) Re: session management with database: optimal parameters in php.ini
    ... make it so simple that there are obviously no deficiencies, ... but I never used their db session management myself. ... But you can simply check it yourself with the 20 frames. ... Unfortunately my scripts are not suspended during the row blocking. ...
    (alt.php)
  • Re: Session variables and frames
    ... the server side, the objects from the client side (frames, documents, ... regarding your doubs about global/session variables: ... A session variable will exist as long as the session exist, ... frames, although the question isn't necessarily about the workings of the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Session variables and frames
    ... the server side, the objects from the client side (frames, documents, ... regarding your doubs about global/session variables: ... A session variable will exist as long as the session exist, ... frames, although the question isn't necessarily about the workings of the ...
    (microsoft.public.dotnet.framework.aspnet)