Gossamer Forum
Home : Products : Gossamer Links : Development, Plugins and Globals :

GT::Session::File problems

Quote Reply
GT::Session::File problems
Hi,

I started using GT::Session::File module to manage sessions on my site.
Currently for some reasons, I don't want to use GT::Session::SQL, so please don't recommend me the SQL based session management.

I found that GT::Session::File module works strangely.
  1. there is no separate method to read the session data. Tough using data() method, data read is possible, I think there should be also need a data_read() method to just read session data.

  2. no correct method, to check existance of a session. Tough it is possible through this code:
    Code:
    # Load a session
    my $session = new GT::Session::File ( $id ) or die "Can't load session: '$id'.";
    but this still creates new sessions for each case when we do checking call & session is missing. It's not fine to create a dummy session file, just because we wanted to check session existance.
    Yes, there could be possible to use if (-e $session_path/$session_id) for existance check, however why is the API if I have to do everything manually?
    I assume this is a bug or a lack of session check feature.

  3. The recommended way by doc is, to set directory path using this code:
    Code:
    # Set session directory
    my $session = new GT::Session::File ( directory => '/path/to/sessions', id => $id );
    However it is bad, since creates new session file, which will be not used for anything.

    Recommended way should be:
    Code:
    $GT::Session::File::DIRECTORY = $sessions_path;

  4. EDIT: One more bug: When printing out the session object using Dumper for debugging reasons, I see that the 'directory' value is missing, even if was previously set by $GT::Session::File::DIRECTORY = $sessions_path; code.
    The 'directory' value should be always the actual value of $DIRECTORY variable!

Did anybody else face such problems with GT::Session::File?

Alex, GT: do you plan improving the API interface of GT::Session::File in near future?

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: May 8, 2003, 9:22 AM
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Quote:
there is no separate method to read the session data. Tough using data() method, data read is possible, I think there should be also need a data_read() method to just read session data.

Noneed for a seperate routine IMO - just use:

my $data = $ses->data();

It's clear and concise.

Quote:
no correct method, to check existance of a session.

You shouldn't need to check the existance except when loading the session file, which is when you create a new session object anyway and so can check for errors. If you already have a session object then that means the session is valid, otherwise new() would have returned an error.

Quote:
The recommended way by doc is, to set directory path using this code:

However it is bad, since creates new session file, which will be not used for anything.

Did you try this out?...it doesn't actually create a new redundant session file. If you pass in id => $id then it loads the existing session file and updates the directory path at the same time.

Quote:
One more bug: When printing out the session object using Dumper for debugging reasons, I see that the 'directory' value is missing, even if was previously set by $GT::Session::File::DIRECTORY = $sessions_path; code.

Mmm no it's not a bug, if you are priting out the session object, then of course $DIRECTORY won't be shown because it's not part of the object, it's a global scalar.

Quote:
Did anybody else face such problems with GT::Session::File?

No.
Quote Reply
Re: [Paul] GT::Session::File problems In reply to
Quote:
Noneed for a seperate routine IMO - just use:
my $data = $ses->data();
It's clear and concise.
Ok. That's your opinion.

Quote:
You shouldn't need to check the existance except when loading the session file, which is when you create a new session object anyway and so can check for errors. If you already have a session object then that means the session is valid, otherwise new() would have returned an error.
When as you say "you create a new session object anyway", unfortunately a new session file is created anyway, even if you just want session checking. I found no solution to avoid creating new session file, when you create new session object.
The only solution is independent of the module: (-e "$session_path/$session_id")
That's what I currently use.

Quote:
Did you try this out?...it doesn't actually create a new redundant session file.
Yes of course I tried out, otherwise I wouldn't post that thread.

Quote:
If you pass in id => $id then it loads the existing session file and updates the directory path at the same time.
But if session file doesn't exist, will create a new session file.

Quote:
Mmm no it's not a bug, if you are priting out the session object, then of course $DIRECTORY won't be shown because it's not part of the object, it's a global scalar.
Doesn't really matter how we name it. Anyway, it would help finding problems, when I do debugging using Dumper. I would logically await the actual value of $DIRECTORY as 'directory' key value.

However I better worry about the fact that new session is created, when I want to check a non-existant session.

I use several non-GT modules, which may affect how this module works, and *may* cause the problem (e.g. CGI.pm).

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Quote:
unfortunately a new session file is created anyway, even if you just want session checking.

That doesn't happen for me.

Quote:
Doesn't really matter how we name it.

I think maybe you misunderstood the point I was making. $DIRECTORY is a global used within GT::Session::File and is not part of the object that GT::Session::File creates, therefore it will not show in a dump of the object.
Quote Reply
Re: [Paul] GT::Session::File problems In reply to
Quote:
I think maybe you misunderstood the point I was making. $DIRECTORY is a global used within GT::Session::File and is not part of the object that GT::Session::File creates, therefore it will not show in a dump of the object.
Yes, I know, it is global in that package: $GT::Session::File::DIRECTORY. Of course.

Quote:
will not show in a dump of the object.
That depends only on intention of developers... Wink

Here is the bugfix:
in new() method instead of following code:
Code:
# We got passed some options, possibly a session id.
if (@_ > 1) {
my $opts = $self->common_param(@_);
foreach (keys %$opts) {
exists $self->{$_} and ($self->{$_} = $opts->{$_});
}
if ($self->{directory}) {
$DIRECTORY = $self->{directory};
}
}

the following is used:
Code:
# We got passed some options, possibly a session id.
if (@_ > 1) {
my $opts = $self->common_param(@_);
foreach (keys %$opts) {
exists $self->{$_} and ($self->{$_} = $opts->{$_});
}
if ($self->{directory}) {
$DIRECTORY = $self->{directory};
}
}
$self->{directory} = $DIRECTORY unless $self->{directory};
The *bugfix* would be so simple...
Tried & works. Cool

Bug nr.4. corrected.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
"bugfix" implies existing code that was not working correctly, which isn't the case, so it's not a bug fix, it's just a custom hack.
Quote Reply
Re: [Paul] GT::Session::File problems In reply to
That simply does not matter. What really matters, that now 1 of 4 problems works as expected.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Solution to problem 1 is also simple:
Code:
sub data_read {
# ---------------------------------------------------------------
# Retrieve the data from the session
#
return $_[0]->{data};
}

It's alternative of data() method. It just reads the data, so we can not overwrite session data by mistake.

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Last edited by:

webmaster33: May 8, 2003, 3:22 PM
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Quote:
That simply does not matter.

You're right, but we should be politically correct =)
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
The 3rd problem is just a doc change, so it can be easily changed.
So 3 of 4 problems can be assumed as solved.

The only problem what remains is the nr.2.
Currently, the workaround for it is, to use: if (-e "/path/to/dir/$session_id");

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Post deleted by webmaster33 In reply to
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Again a BUG in GT::Session::File module.
There is no file locking used in this module at all!

Code:
sub save {
...
my $fh = \do {local *FH; *FH};
open ($fh, "> $file") or return $self->error ('CANTOPEN', 'FATAL', $file, "$!");
my $dump = GT::Dumper->dump(
var => '$SESSION',
data => $self->{data}
);
print $fh $dump;
close $fh;
...
}

flock() should be used to avoid multiple process access to the same file (read or write) at the same time!

I'm afraid this is true for all Links SQL system as I did read strange data losses on config file, plugin config files, or other file based storages!!!
This is shame Frown

Links SQL does not have support, to be used in race condition environment (except for the database access where the table or row locking is a database dependent feature)!
It should be updated/modified to have file locking used in ALL file reads & writes!

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
GT::Session::File doesn't need file locking.

Each session file is unique for each visitor so the same file will never be used by more than one client so there is no risk of corrupting the file.

Secondly, the session file is loaded using do() and not open() and so there is no risk there either.
Quote Reply
Re: [Paul] GT::Session::File problems In reply to
GT::Session::File needs also file locking as well ALL open() operation (read or write).

While each session file is unique for each visitor, the visitors many times double clicks to buttons. Therefore the data loss chance is not much less as if the file would be used by many users.
As you know there were several config file data losses for LSQL users on admin interface which has very rare change since usually 1 user uses the admin interface. Likely when an admin double clicked an Update button. So nothing is impossible.

The session file is opened with open():
open ($fh, "> $file") or return $self->error ('CANTOPEN', 'FATAL', $file, "$!");
The do() doesn't matter. After the open() there is GT::Dumper->dump used, and several tasks are done there.
Therefore there *IS* the time slice where 2 processes can which was caused by user multiple click.

But the biggest problem is that it seems, flock() is not used in LSQL almost at all!
The only place where flock is used: GT::FileMan::Commands, which is not really related to other LSQL parts...

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...
Quote Reply
Re: [webmaster33] GT::Session::File problems In reply to
Quote:
GT::Session::File needs also file locking as well ALL open() operation (read or write).

I'm not sure what you mean.

Quote:
While each session file is unique for each visitor, the visitors many times double clicks to buttons. Therefore the data loss chance is not much less as if the file would be used by many users.

A double click simply means a new session file will get created - the original won't be overwritten. File locking is used when one file is accessed by multiple people.

Quote:
The session file is opened with open():
open ($fh, "> $file") or return $self->error ('CANTOPEN', 'FATAL', $file, "$!");
The do() doesn't matter. After the open() there is GT::Dumper->dump used, and several tasks are done there.
Therefore there *IS* the time slice where 2 processes can which was caused by user multiple click.

Yes but as described above, if the user double clicks then all that will happen is a new session file will be created as the file names are random.
Quote Reply
Re: [Paul] GT::Session::File problems In reply to
Quote:
A double click simply means a new session file will get created - the original won't be overwritten. File locking is used when one file is accessed by multiple people.
Uh, nooo! It depends on what you do in the script!
If you take the session id from cookie or pass through the form, you will use the same session all the time. That's why do you use session, don't you?...

Best regards,
Webmaster33


Paid Support
from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...