cgi-session-user — CGI::Session users mailing list

[Cgi-session-user] CGI::Session for <sessions driver="SQLite" dbname="sessions"/>

[c.h. c. <c.h...@nx...>]

Hi there,

Now I'm working an existing Perl web application migration to a new Windows server.
But I encounters the problem that Perl web application does not work at new Windows server.

I check that config.xml that includes the statement below.

  <sessions driver="SQLite" dbname="sessions"/>

I guess that it needs CGI::Session, right?

So how do I setup the Perl module of CGI::Session?
In the C:\Strawberry\perl\site\lib\CGI\Session ?

Or any other referenced or related Perl modules I need for CGI::Session?

Many thanks in advance.

Best regards,

C.H. Chou

Re: [Cgi-session-user] utf8 problem

[Ron S. <ro...@sa...>]

Hi Thomas

Thanx for the detailed reply.

I wrote Data::Session as a modernized version of CGI::Session, and in 
its docs:

https://metacpan.org/pod/Data::Session

you can search for 'utf8' to find a little bit of info. The context is 
UUID16, which I guess does not help, but it's a far as I've investigated 
in the past.

The other reference to 'utf8' is in:

https://metacpan.org/pod/Data::Session::ID::UUID16

If I hit this problem, my first idea would be to use SHA1 to encode the 
session. I have no idea if it would help.

HTH.

On 13/07/15 20:40, Thomas Glase wrote:
> Hi Ron,
>
> Thank you for the quick response.
>
> You are right, turning the session data column into binary blob does work.
> But in my present scenario the db column is preferred to be human readable.
> Also, saving the session data in a binary column without a collation
> rather avoids the whole encoding issue right?
>
> If I write the session data to a file with Path::Tiny::spew_utf8 the
> string is stored as expected 'jörg'.
> Aside from the session table, the name is also stored in a 'person' db
> table but without using Data::Dumper of course, and reading/writing from
> there works fine with utf-8 characters.
>
> I made some tests using Devel::Peek and before it gets stored to db via
> Data::Dumper, the session parameter 'jörg' has the utf8 flag set
> alright, after thawing it doesn't anymore.
> So, I tried calling utf8::upgrade manually on each session parameter
> right after thawing and this would work indeed, but in general there
> might be various nested structures in the session which makes that
> workaround inconvenient.
>
> Interestingly, using YAML as a serializer yields similar results. On
> thaw the session parameters are not decoded properly into perls internal
> format. Manually calling decode_utf8 for each session parameter right
> after thaw would fix it, but like above it's not convenient.
>
> So I'm wondering if I'm just missing a parameter which could tell
> CGI::Session to expect utf8 data and deserialize it accordingly, thereby
> not making assumptions about it. Or is there indeed no other way than to
> manually iterate over the whole session data structure?
>
> Best regards,
> Thomas
>> Ron Savage <mailto:ro...@sa...>
>> Freitag, 10. Juli 2015 00:42
>> Hi Thomas
>>
>> There's another issue, which I omitted from my 1st email on the
>> assumption it was obvious, but perhaps it isn't.
>>
>> (Ideally) You should not be writing or using code which makes
>> assumptions about the 'utf8 flag'.
>>
>> So, try opening a file with the utf-8 layer active, and just write the
>> session data to the file, without using Data::Dumper.
>>
>> Use https://metacpan.org/release/Path-Tiny, say, for that.
>>
>>
>> Thomas Glase <mailto:tho...@pi...>
>> Donnerstag, 9. Juli 2015 14:36
>> Hi,
>>
>> I'm having problems getting CGI::Session to work with utf8.
>> I read the "A Warning about UTF8" section but I couldn't find the
>> following issue anywhere:
>>
>> In my session I have utf8 encoded strings like 'jörg'.
>>
>> The session data gets serialized by default serializer Data::Dumper into
>> a MySQL data column (mediumtext, charset utf8, collation
>> utf8_unicode_ci) as expected with utf8 characters escaped like this:
>> 'j\x{f6}rg'
>>
>> Now, the problem is that when this session data get's thawed, the
>> resulting string 'jörg' is missing perls utf8 flag. Which causes
>> Data::Dumper to just cut the data at the utf8 character 'ö' during next
>> freeze. Result: the dump is stored corrupted in the data column and
>> Data::Dumper crashes of course when trying to thaw that next time.
>>
>> I already posted this problem incl more details and code snippets at
>> stackoverflow to no avail:
>>
>> http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data
>>
>>
>>
>> It looks like a bug to me but since I don't think that I'm the only one
>> trying to use CGI::Session with utf8 characters I guess that I rather
>> must be missing something here.
>>
>> I'd be really grateful for any hints on this.
>>
>> Best regards,
>> Thomas
>>
>>
>> ------------------------------------------------------------------------------
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> _______________________________________________
>> Cgi-session-user mailing list
>> Cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>> Thomas Glase <mailto:tho...@pi...>
>> Donnerstag, 9. Juli 2015 13:29
>> Hi,
>>
>> I'm having problems getting CGI::Session to work with utf8.
>> I read the "A Warning about UTF8" section but I couldn't find the
>> following issue anywhere:
>>
>> In my session I have utf8 encoded strings like 'jörg'.
>>
>> The session data gets serialized by default serializer Data::Dumper
>> into a MySQL data column (mediumtext, charset utf8, collation
>> utf8_unicode_ci) as expected with utf8 characters escaped like this:
>> 'j\x{f6}rg'
>>
>> Now, the problem is that when this session data get's thawed, the
>> resulting string 'jörg' is missing perls utf8 flag. Which causes
>> Data::Dumper to just cut the data at the utf8 character 'ö' during
>> next freeze. Result: the dump is stored corrupted in the data column
>> and Data::Dumper crashes of course when trying to thaw that next time.
>>
>> I already posted this problem incl more details and code snippets at
>> stackoverflow to no avail:
>>
>> http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data
>>
>>
>> It looks like a bug to me but since I don't think that I'm the only
>> one trying to use CGI::Session with utf8 characters I guess that I
>> rather must be missing something here.
>>
>> I'd be really grateful for any hints on this.
>>
>> Best regards,
>> Thomas
>>
>
> --
>
> Thomas Glase
> Software Developer
>
> Piranha Arts AG * Kreuzbergstr. 30 * 10965 Berlin * Germany
> Tel+49 30  318 614-21  * Fax+49 30  318 614-10
>
> www.piranha-arts.com
>
> -----------------------------------------------------------
> Mark your calendars ...
> :::21 - 25  Oct 2015, WOMEX, Budapest, Hungary
> :::25 - 28  May 2016, Classical:NEXT, Rotterdam, the Netherlands
> ----------------------------------------------------------
>
> This email was sent by: Piranha Arts AG * Berlin HRB 63466
> Vorstand F.Klaffs & M.v.Petrykowski * AR-Vorsitzender C.Borkowsky
>
> Disclaimer: Any statements in this email or attachment explicitly
> do not constitute a contract or a legally binding agreement with
> Piranha Arts AG.
>
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
>
>
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

-- 
Ron Savage - savage.net.au

Re: [Cgi-session-user] utf8 problem

[Thomas G. <tho...@pi...>]

Hi Ron,

Thank you for the quick response.

You are right, turning the session data column into binary blob does work.
But in my present scenario the db column is preferred to be human readable.
Also, saving the session data in a binary column without a collation 
rather avoids the whole encoding issue right?

If I write the session data to a file with Path::Tiny::spew_utf8 the 
string is stored as expected 'jörg'.
Aside from the session table, the name is also stored in a 'person' db 
table but without using Data::Dumper of course, and reading/writing from 
there works fine with utf-8 characters.

I made some tests using Devel::Peek and before it gets stored to db via 
Data::Dumper, the session parameter 'jörg' has the utf8 flag set 
alright, after thawing it doesn't anymore.
So, I tried calling utf8::upgrade manually on each session parameter 
right after thawing and this would work indeed, but in general there 
might be various nested structures in the session which makes that 
workaround inconvenient.

Interestingly, using YAML as a serializer yields similar results. On 
thaw the session parameters are not decoded properly into perls internal 
format. Manually calling decode_utf8 for each session parameter right 
after thaw would fix it, but like above it's not convenient.

So I'm wondering if I'm just missing a parameter which could tell 
CGI::Session to expect utf8 data and deserialize it accordingly, thereby 
not making assumptions about it. Or is there indeed no other way than to 
manually iterate over the whole session data structure?

Best regards,
Thomas
> Ron Savage <mailto:ro...@sa...>
> Freitag, 10. Juli 2015 00:42
> Hi Thomas
>
> There's another issue, which I omitted from my 1st email on the
> assumption it was obvious, but perhaps it isn't.
>
> (Ideally) You should not be writing or using code which makes
> assumptions about the 'utf8 flag'.
>
> So, try opening a file with the utf-8 layer active, and just write the
> session data to the file, without using Data::Dumper.
>
> Use https://metacpan.org/release/Path-Tiny, say, for that.
>
>
> Thomas Glase <mailto:tho...@pi...>
> Donnerstag, 9. Juli 2015 14:36
> Hi,
>
> I'm having problems getting CGI::Session to work with utf8.
> I read the "A Warning about UTF8" section but I couldn't find the
> following issue anywhere:
>
> In my session I have utf8 encoded strings like 'jörg'.
>
> The session data gets serialized by default serializer Data::Dumper into
> a MySQL data column (mediumtext, charset utf8, collation
> utf8_unicode_ci) as expected with utf8 characters escaped like this:
> 'j\x{f6}rg'
>
> Now, the problem is that when this session data get's thawed, the
> resulting string 'jörg' is missing perls utf8 flag. Which causes
> Data::Dumper to just cut the data at the utf8 character 'ö' during next
> freeze. Result: the dump is stored corrupted in the data column and
> Data::Dumper crashes of course when trying to thaw that next time.
>
> I already posted this problem incl more details and code snippets at
> stackoverflow to no avail:
>
> http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data 
>
>
>
> It looks like a bug to me but since I don't think that I'm the only one
> trying to use CGI::Session with utf8 characters I guess that I rather
> must be missing something here.
>
> I'd be really grateful for any hints on this.
>
> Best regards,
> Thomas
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> Thomas Glase <mailto:tho...@pi...>
> Donnerstag, 9. Juli 2015 13:29
> Hi,
>
> I'm having problems getting CGI::Session to work with utf8.
> I read the "A Warning about UTF8" section but I couldn't find the 
> following issue anywhere:
>
> In my session I have utf8 encoded strings like 'jörg'.
>
> The session data gets serialized by default serializer Data::Dumper 
> into a MySQL data column (mediumtext, charset utf8, collation 
> utf8_unicode_ci) as expected with utf8 characters escaped like this: 
> 'j\x{f6}rg'
>
> Now, the problem is that when this session data get's thawed, the 
> resulting string 'jörg' is missing perls utf8 flag. Which causes 
> Data::Dumper to just cut the data at the utf8 character 'ö' during 
> next freeze. Result: the dump is stored corrupted in the data column 
> and Data::Dumper crashes of course when trying to thaw that next time.
>
> I already posted this problem incl more details and code snippets at 
> stackoverflow to no avail:
>
> http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data 
>
>
> It looks like a bug to me but since I don't think that I'm the only 
> one trying to use CGI::Session with utf8 characters I guess that I 
> rather must be missing something here.
>
> I'd be really grateful for any hints on this.
>
> Best regards,
> Thomas
>

-- 

Thomas Glase
Software Developer

Piranha Arts AG * Kreuzbergstr. 30 * 10965 Berlin * Germany
Tel+49 30  318 614-21  * Fax+49 30  318 614-10

www.piranha-arts.com

-----------------------------------------------------------
Mark your calendars ...
:::21 - 25  Oct 2015, WOMEX, Budapest, Hungary
:::25 - 28  May 2016, Classical:NEXT, Rotterdam, the Netherlands
----------------------------------------------------------

This email was sent by: Piranha Arts AG * Berlin HRB 63466
Vorstand F.Klaffs&  M.v.Petrykowski * AR-Vorsitzender C.Borkowsky

Disclaimer: Any statements in this email or attachment explicitly
do not constitute a contract or a legally binding agreement with
Piranha Arts AG.

Re: [Cgi-session-user] utf8 problem

[Ron S. <ro...@sa...>]

Hi Thomas

My immediate reaction is to suggest you redefine the column holding 
sesions to be a binary blob of some sort. The syntax will vary from db 
to db, of course.

Please let us know how that turns out.


On 09/07/15 22:36, Thomas Glase wrote:
> Hi,
>
> I'm having problems getting CGI::Session to work with utf8.
> I read the "A Warning about UTF8" section but I couldn't find the
> following issue anywhere:
>
> In my session I have utf8 encoded strings like 'jörg'.
>
> The session data gets serialized by default serializer Data::Dumper into
> a MySQL data column (mediumtext, charset utf8, collation
> utf8_unicode_ci) as expected with utf8 characters escaped like this:
> 'j\x{f6}rg'
>
> Now, the problem is that when this session data get's thawed, the
> resulting string 'jörg' is missing perls utf8 flag. Which causes
> Data::Dumper to just cut the data at the utf8 character 'ö' during next
> freeze. Result: the dump is stored corrupted in the data column and
> Data::Dumper crashes of course when trying to thaw that next time.
>
> I already posted this problem incl more details and code snippets at
> stackoverflow to no avail:
>
> http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data
>
>
> It looks like a bug to me but since I don't think that I'm the only one
> trying to use CGI::Session with utf8 characters I guess that I rather
> must be missing something here.
>
> I'd be really grateful for any hints on this.
>
> Best regards,
> Thomas
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

-- 
Ron Savage - savage.net.au

Re: [Cgi-session-user] utf8 problem

[Ron S. <ro...@sa...>]

Hi Thomas

There's another issue, which I omitted from my 1st email on the 
assumption it was obvious, but perhaps it isn't.

(Ideally) You should not be writing or using code which makes 
assumptions about the 'utf8 flag'.

So, try opening a file with the utf-8 layer active, and just write the 
session data to the file, without using Data::Dumper.

Use https://metacpan.org/release/Path-Tiny, say, for that.


-- 
Ron Savage - savage.net.au

[Cgi-session-user] utf8 problem

[Thomas G. <tho...@pi...>]

Hi,

I'm having problems getting CGI::Session to work with utf8.
I read the "A Warning about UTF8" section but I couldn't find the 
following issue anywhere:

In my session I have utf8 encoded strings like 'jörg'.

The session data gets serialized by default serializer Data::Dumper into 
a MySQL data column (mediumtext, charset utf8, collation 
utf8_unicode_ci) as expected with utf8 characters escaped like this: 
'j\x{f6}rg'

Now, the problem is that when this session data get's thawed, the 
resulting string 'jörg' is missing perls utf8 flag. Which causes 
Data::Dumper to just cut the data at the utf8 character 'ö' during next 
freeze. Result: the dump is stored corrupted in the data column and 
Data::Dumper crashes of course when trying to thaw that next time.

I already posted this problem incl more details and code snippets at 
stackoverflow to no avail:

http://stackoverflow.com/questions/31049125/perl-cgisession-mysql-thaw-utf-8-data 


It looks like a bug to me but since I don't think that I'm the only one 
trying to use CGI::Session with utf8 characters I guess that I rather 
must be missing something here.

I'd be really grateful for any hints on this.

Best regards,
Thomas

Re: [Cgi-session-user] CGI::Session hangs (but probably some other component is to blame)

[Ron S. <ro...@sa...>]

Hi Dave

See below.

On 11/05/15 05:00, David Levner wrote:
> /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine (eval)(), line 28.
>      Called from package CGI::Session::Serialize::Default, file

CGI::Session::Serialize::Default is not part of the CGI::Session distro.

So, where did it come from?

And why does it call B.pm?

Anyway, there's your problem :-(.

> ../foreign-lib/CGI/Session/Serialize/Default.pm, subroutine (eval)(),
> line 5.
>      Called from package main, file

-- 
Ron Savage - savage.net.au

[Cgi-session-user] CGI::Session hangs (but probably some other component is to blame)

[David L. <dav...@ya...>]

I have some web sites that use CGI:: Session to maintain state information (so user can log in). Occasionally, a user requests a web page and does not get a response because the CGI script gets stuck somewhere. I added a call to alarm(100) at the start of my CGI script to send the SIGALRM signal after 100 seconds. The subroutine that catches the alarm prints diagnostic information to a log file (see below).
It appears that CGI::Session is getting stuck in XSLoader.pm. As is clear from the log file, the CGI script is running under NetBSD with Perl 5.14.2.
I only have a limited understanding of what the dynamic loader is doing. I welcome any suggestions that would help me avoid this problem. My guess is that this a NetBSD issue--I am considering (for other reasons) using a different hosting service where the OS would be a version of Linux. Do you think that would be an improvement?
Here is the raw output from the log file:
    !Sun May 10 09:30:25 2015: 'This page is taking too long to load--something is wrong.'
    !Called from package Debug, file /htdocs/userdirs/levner/orgs-dev/lib/releases/20150417-p20150304/Debug.pm, subroutine DB::stack_output(), line 502.
    Called from package CGILogin::Util, file /htdocs/userdirs/levner/orgs-dev/lib/releases/20150417-p20150304/CGILogin/Util.pm, subroutine Debug::must_print_stack(), line 179.
    Called from package CGILogin::Util, file /htdocs/userdirs/levner/orgs-dev/lib/releases/20150417-p20150304/CGILogin/Util.pm, subroutine CGILogin::Util::handle_web_errors('This page is taking too long to load--something is wrong.'), line 268.
    Called from package DynaLoader, file /usr/local/lib/perl5/5.14.2/XSLoader.pm, subroutine CGILogin::Util::catch_alarm('ALRM'), line 95.
    Called from package DynaLoader, file /usr/local/lib/perl5/5.14.2/XSLoader.pm, subroutine (eval)('ALRM'), line 95.
    Called from package B, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine XSLoader::load('B'), line 27.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine B::BEGIN(), line 28.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine (eval)(), line 28.
    Called from package Safe, file /usr/local/lib/perl5/5.14.2/Safe.pm, subroutine (eval)(), line 34.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine Safe::BEGIN(), line 28.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine (eval)(), line 28.
    Called from package CGI::Session::Serialize::Default, file ../foreign-lib/CGI/Session/Serialize/Default.pm, subroutine (eval)(), line 5.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine CGI::Session::Serialize::Default::BEGIN(), line 28.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine (eval)(), line 28.
    Called from package base, file (eval 33), subroutine (eval)(), line 2.
    Called from package base, file /usr/local/lib/perl5/5.14.2/base.pm, subroutine (eval)(), line 91.
    Called from package CGI::Session::File, file ../foreign-lib/CGI/Session/File.pm, subroutine base::import('base', 'CGI::Session', 'CGI::Session::ID::MD5', 'CGI::Session::Serialize::Default'), line 8.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine CGI::Session::File::BEGIN(), line 28.
    Called from package main, file /usr/local/lib/perl5/5.14.2/i386-netbsd/B.pm, subroutine (eval)(), line 28.
    Called from package CGI::Session, file (eval 31), subroutine (eval)(), line 2.
    Called from package CGI::Session, file ../foreign-lib/CGI/Session.pm, subroutine (eval)(), line 98.
    Called from package CGI::Session, file ../foreign-lib/CGI/Session.pm, subroutine CGI::Session::api_3('CGI::Session', 'driver:File', '', ['Directory' => 'sessions']), line 50.
    Called from package CGILogin, file /htdocs/userdirs/levner/orgs-dev/lib/releases/20150417-p20150304/CGILogin.pm, subroutine CGI::Session::new('CGI::Session', 'driver:File', '', ['Directory' => 'sessions']), line 326.
    Called from package main, file index.cgi, subroutine CGILogin::new('CGILogin'), line 260.
 David

Re: [Cgi-session-user] Storable binary image v18.68 more recent than I am (v2.7) at

[Ron S. <ro...@sa...>]

Hi Mimi

There are various possibilities. Some are:

o The server did get upgraded.

o Your program is now running on a different server.

o Your program is taking a different path thru the code and no long 
executes the statement which caused the error.

o Your program deleted the file and the re-executed the statement which 
caused the error.

o The file the program was trying to read has been deleted outside your 
program, so your program now creates and reads it using the same version 
of Storable.

As you can see, it's very difficult to know exactly what happened.

Good luck!

On 18/02/15 23:09, mim...@gm... wrote:
> Strangely, CGI::Session now working with storable without error. As far
> as I am aware, no updates were done on the server. It would interested
> me to know if anyone has had the error and how the fixed it.
>
> Mimi
>
> On 18 February 2015 at 10:09, mim...@gm...
> <mailto:mim...@gm...> <mim...@gm...
> <mailto:mim...@gm...>> wrote:
>
>     I get the following error when I call new with "serializer:storable"
>     as below:
>
>     my $session = new CGI::Session('driver:mysql;serializer:storable',
>     undef, { Handle => $dbh}) or die CGI::Session->errstr;
>
>
>
>     error_2015_02_12_Thu.log:[Thu Feb 12 13:10:44 2015] [error] Storable
>     binary image v18.68 more recent than I am (v2.7) at
>     ../../lib/Storable.pm (autosplit into
>     ../../lib/auto/Storable/thaw.al <http://thaw.al>) line 415, at
>     /usr/share/perl5/vendor_perl/CGI/Session/Serialize/storable.pm
>     <http://storable.pm> line 51.\n
>
>
>     However my session work fine without storable.
>
>     # This works
>          my $session = new CGI::Session('driver:mysql', undef, { Handle
>     => $dbh}) or die CGI::Session->errstr;
>
>     Anyone seen this of understand why I get the error?
>
>     Mimi
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

-- 
Ron Savage - savage.net.au

Re: [Cgi-session-user] Storable binary image v18.68 more recent than I am (v2.7) at

[<mim...@gm...>]

Strangely, CGI::Session now working with storable without error. As far as
I am aware, no updates were done on the server. It would interested me to
know if anyone has had the error and how the fixed it.

Mimi

On 18 February 2015 at 10:09, mim...@gm... <mim...@gm...> wrote:

> I get the following error when I call new with "serializer:storable" as
> below:
>
> my $session = new CGI::Session('driver:mysql;serializer:storable', undef,
> { Handle => $dbh}) or die CGI::Session->errstr;
>
>
>
> error_2015_02_12_Thu.log:[Thu Feb 12 13:10:44 2015] [error] Storable
> binary image v18.68 more recent than I am (v2.7) at ../../lib/Storable.pm
> (autosplit into ../../lib/auto/Storable/thaw.al) line 415, at
> /usr/share/perl5/vendor_perl/CGI/Session/Serialize/storable.pm line 51.\n
>
>
> However my session work fine without storable.
>
> # This works
>     my $session = new CGI::Session('driver:mysql', undef, { Handle =>
> $dbh}) or die CGI::Session->errstr;
>
> Anyone seen this of understand why I get the error?
>
> Mimi
>

[Cgi-session-user] Storable binary image v18.68 more recent than I am (v2.7) at

[<mim...@gm...>]

I get the following error when I call new with "serializer:storable" as
below:

my $session = new CGI::Session('driver:mysql;serializer:storable', undef, {
Handle => $dbh}) or die CGI::Session->errstr;



error_2015_02_12_Thu.log:[Thu Feb 12 13:10:44 2015] [error] Storable binary
image v18.68 more recent than I am (v2.7) at ../../lib/Storable.pm
(autosplit into ../../lib/auto/Storable/thaw.al) line 415, at
/usr/share/perl5/vendor_perl/CGI/Session/Serialize/storable.pm line 51.\n


However my session work fine without storable.

# This works
    my $session = new CGI::Session('driver:mysql', undef, { Handle =>
$dbh}) or die CGI::Session->errstr;

Anyone seen this of understand why I get the error?

Mimi

[Cgi-session-user] Storable binary image v18.68 more recent than I am (v2.7)

[<mim...@gm...>]

Hi

Re: [Cgi-session-user] ORA-03124

[Junji O. <_j...@wa...>]

Hi Ron

Thank you for everything so far.
I will do as you advised.
I had a good time to talk with you.

Have a nice year.

(2013/12/19 14:46), Ron Savage wrote:
> Hi Junji
>
> On 19/12/13 15:14, Junji Ochi wrote:
>> Hi Ron
>>
>> I'm so sorry to take your time for some extra work with my fault.
>> I should be more careful to my words.
>
> No problem!
>
>>    > But (guessing) perhaps the app stores \x0 (null) into the session?
>>    > Or perhaps it stores a value which contains a control char?
>> It could be. I need more investigation.
>
> Don't spend too much time on it. Now you know how to set the column
> types, the problem is solved.
>
>> I have two more questions.
>>
>> 1. Which do you think there is a problem of perl or Oracle?
>
> It's the combination. Perl definitely assumes /any/ string of chars can
> be stored in the a_session column, where as (IMHO) Oracle is imposing
> some sort of constraint on the chars (or on their sequence).
>
>> 2. ORA-03124 comes out at "$sth->fetchrow_array()" line
>> on CGI/Session/Driver/DBI.pm line 74
>> Is this your code ?
>> or
>> DBD::Oracle::st's author know a clue?
>> pelase see below quote
>
> CGI::Session::Driver::DBI was I believe written by the original author
> of CGI::Session, Sherzod Ruzmetov. He has not been sighted on this list
> for quite a few years now.
>
> The error is caused by the execution of code in
> CGI::Session::Driver::DBI, but it is DBD::Oracle which is detecting and
> reporting the error.
>
>> /////qw start/////
>> DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal
>> error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM
>> TEST_TB WHERE ID=?" with ParamValues:
>> :p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at
>> CGI/Session/Driver/DBI.pm line 74.
>> /////qw end/////
>>
>> Sincerely,
>>
>> (2013/12/19 10:51), Ron Savage wrote:
>>> Hi Junji
>>>
>>> Note: I'm on the mailing list, so no need to copy me personally.
>>>
>>> More below.
>>>
>>> On 19/12/13 12:12, Junji Ochi wrote:
>>>> Good morning Ron
>>>>
>>>> I had a screw-up.
>>>>
>>>> I said that changing the ID col data type to VARCHAR2 would be a
>>>> workarround.
>>>> but ,It doesn't matter if the ID col is VARCHAR2 or CHAR
>>>>
>>>> I tested again for you.
>>>> +--------+---------+--------+
>>>> |ID      |A_SESSION|RESULT  |
>>>> +--------+---------+--------+
>>>> |CHAR    |VARCHAR2 |NOT WORK|
>>>> +--------+---------+--------+
>>>> |VARCHAR2|VARCHAR2 |NOT WORK|
>>>> +--------+---------+--------+
>>>> |CHAR    |LONG     |WORK    |
>>>> +--------+---------+--------+
>>>> |VARCHAR2|LONG     |WORK    |
>>>> +--------+---------+--------+
>>>> |CHAR    |CLOB     |WORK    |
>>>> +--------+---------+--------+
>>>> |VARCHAR2|CLOB     |WORK    |
>>>> +--------+---------+--------+
>>>
>>> Thanx for doing these tests.
>>>
>>> This is of great importance because I've already patched
>>> CGI::Session::Driver::oracle and (my fork)
>>> Data::Session::Driver::Oracle, but have not released them :-)).
>>>
>>> Now I won't have to, and using git I can just roll back the code to the
>>> previous release :-).
>>>
>>>> It seemed VARCHAR2 on A_SESSION col caused problem.
>>>>
>>>> I have two question.
>>>> 1.Should we use LONG type on A_SESSION col after all?
>>>
>>> Yes. It used to work, and I've just read the Oracle docs you linked to,
>>> and I don't think we need worry about all the restrictions Oracle
>>> mentioned pertaining to long. The code only uses the long field in a
>>> /very/ simple way.
>>>
>>> BTW Don't forget that the id field is fixed-width. That is, once the
>>> program runs, all values written into the id field are the same length.
>>>
>>> So char(N) makes sense there.
>>>
>>>> 2.Could you explain why VARCHAR2 cause problem. Was the data type
>>>> strictly checked on A_SESSION col ?
>>>
>>> I think so. This link
>>> http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50956
>>>
>>> points to text which says 'To ensure proper data conversion between
>>> databases with different character sets, you must ensure that VARCHAR2
>>> data consists of well-formed strings.'. That last part, 'well-formed
>>> strings', is very interesting.
>>>
>>> I feel - but can't be sure - that that is what is causing the problem.
>>>
>>> I cannot find any definition of 'well-formed strings' in Oracle's docs,
>>> except for well-formed XML.
>>>
>>> But (guessing) perhaps the app stores \x0 (null) into the session?
>>> Or perhaps it stores a value which contains a control char?
>>>
>>> Cheers
>>> Ron
>>>
>>>> Sincerely,
>>>>
>>>>
>>>> (2013/12/18 15:04), Ron Savage wrote:
>>>>> Hi Junji
>>>>>
>>>>> See below.
>>>>>
>>>>> On 18/12/13 14:14, Junji Ochi wrote:
>>>>>> Hi Ron,
>>>>>>
>>>>>> Thank you for your prompt email reply.
>>>>>>
>>>>>> I changed the table definition by following The dosc.
>>>>>> That works fine.
>>>>>
>>>>> Excellent!
>>>>>
>>>>> And for letting us know:
>>>>>
>>>>> $many x $thanx;
>>>>>
>>>>>>       ID CHAR(40) primary key
>>>>>>       A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG
>>>>>>
>>>>>> But Oracle docs says not use LONG type because it is for backward
>>>>>> compatibility.
>>>>>> ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> and CLOB has some restrictions.
>>>>>> ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's why I choosed the VARCHAR2.
>>>>>>
>>>>>> A_SESSION colums must be LONG type?
>>>>>
>>>>> No I believe it does not have to be. It's just that when that code was
>>>>> written years ago (1st version 2005) I believed it had to be.
>>>>>
>>>>> Since then, Oracle has been upgraded a few times :-).
>>>>>
>>>>> As long as VARCHAR2 works, and it's not deprecated by Oracle, then it's
>>>>> a better choice that what's recommended in the docs.
>>>>>
>>>>> I'd better update the docs.
>>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Cgi-session-user mailing list
>> Cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>>
>

Re: [Cgi-session-user] ORA-03124

[Ron S. <ro...@sa...>]

Hi Junji

On 19/12/13 15:14, Junji Ochi wrote:
> Hi Ron
>
> I'm so sorry to take your time for some extra work with my fault.
> I should be more careful to my words.

No problem!

>   > But (guessing) perhaps the app stores \x0 (null) into the session?
>   > Or perhaps it stores a value which contains a control char?
> It could be. I need more investigation.

Don't spend too much time on it. Now you know how to set the column 
types, the problem is solved.

> I have two more questions.
>
> 1. Which do you think there is a problem of perl or Oracle?

It's the combination. Perl definitely assumes /any/ string of chars can 
be stored in the a_session column, where as (IMHO) Oracle is imposing 
some sort of constraint on the chars (or on their sequence).

> 2. ORA-03124 comes out at "$sth->fetchrow_array()" line
> on CGI/Session/Driver/DBI.pm line 74
> Is this your code ?
> or
> DBD::Oracle::st's author know a clue?
> pelase see below quote

CGI::Session::Driver::DBI was I believe written by the original author 
of CGI::Session, Sherzod Ruzmetov. He has not been sighted on this list 
for quite a few years now.

The error is caused by the execution of code in 
CGI::Session::Driver::DBI, but it is DBD::Oracle which is detecting and 
reporting the error.

> /////qw start/////
> DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal
> error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM
> TEST_TB WHERE ID=?" with ParamValues:
> :p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at
> CGI/Session/Driver/DBI.pm line 74.
> /////qw end/////
>
> Sincerely,
>
> (2013/12/19 10:51), Ron Savage wrote:
>> Hi Junji
>>
>> Note: I'm on the mailing list, so no need to copy me personally.
>>
>> More below.
>>
>> On 19/12/13 12:12, Junji Ochi wrote:
>>> Good morning Ron
>>>
>>> I had a screw-up.
>>>
>>> I said that changing the ID col data type to VARCHAR2 would be a
>>> workarround.
>>> but ,It doesn't matter if the ID col is VARCHAR2 or CHAR
>>>
>>> I tested again for you.
>>> +--------+---------+--------+
>>> |ID      |A_SESSION|RESULT  |
>>> +--------+---------+--------+
>>> |CHAR    |VARCHAR2 |NOT WORK|
>>> +--------+---------+--------+
>>> |VARCHAR2|VARCHAR2 |NOT WORK|
>>> +--------+---------+--------+
>>> |CHAR    |LONG     |WORK    |
>>> +--------+---------+--------+
>>> |VARCHAR2|LONG     |WORK    |
>>> +--------+---------+--------+
>>> |CHAR    |CLOB     |WORK    |
>>> +--------+---------+--------+
>>> |VARCHAR2|CLOB     |WORK    |
>>> +--------+---------+--------+
>>
>> Thanx for doing these tests.
>>
>> This is of great importance because I've already patched
>> CGI::Session::Driver::oracle and (my fork)
>> Data::Session::Driver::Oracle, but have not released them :-)).
>>
>> Now I won't have to, and using git I can just roll back the code to the
>> previous release :-).
>>
>>> It seemed VARCHAR2 on A_SESSION col caused problem.
>>>
>>> I have two question.
>>> 1.Should we use LONG type on A_SESSION col after all?
>>
>> Yes. It used to work, and I've just read the Oracle docs you linked to,
>> and I don't think we need worry about all the restrictions Oracle
>> mentioned pertaining to long. The code only uses the long field in a
>> /very/ simple way.
>>
>> BTW Don't forget that the id field is fixed-width. That is, once the
>> program runs, all values written into the id field are the same length.
>>
>> So char(N) makes sense there.
>>
>>> 2.Could you explain why VARCHAR2 cause problem. Was the data type
>>> strictly checked on A_SESSION col ?
>>
>> I think so. This link
>> http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50956
>>
>> points to text which says 'To ensure proper data conversion between
>> databases with different character sets, you must ensure that VARCHAR2
>> data consists of well-formed strings.'. That last part, 'well-formed
>> strings', is very interesting.
>>
>> I feel - but can't be sure - that that is what is causing the problem.
>>
>> I cannot find any definition of 'well-formed strings' in Oracle's docs,
>> except for well-formed XML.
>>
>> But (guessing) perhaps the app stores \x0 (null) into the session?
>> Or perhaps it stores a value which contains a control char?
>>
>> Cheers
>> Ron
>>
>>> Sincerely,
>>>
>>>
>>> (2013/12/18 15:04), Ron Savage wrote:
>>>> Hi Junji
>>>>
>>>> See below.
>>>>
>>>> On 18/12/13 14:14, Junji Ochi wrote:
>>>>> Hi Ron,
>>>>>
>>>>> Thank you for your prompt email reply.
>>>>>
>>>>> I changed the table definition by following The dosc.
>>>>> That works fine.
>>>>
>>>> Excellent!
>>>>
>>>> And for letting us know:
>>>>
>>>> $many x $thanx;
>>>>
>>>>>      ID CHAR(40) primary key
>>>>>      A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG
>>>>>
>>>>> But Oracle docs says not use LONG type because it is for backward
>>>>> compatibility.
>>>>> ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> and CLOB has some restrictions.
>>>>> ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That's why I choosed the VARCHAR2.
>>>>>
>>>>> A_SESSION colums must be LONG type?
>>>>
>>>> No I believe it does not have to be. It's just that when that code was
>>>> written years ago (1st version 2005) I believed it had to be.
>>>>
>>>> Since then, Oracle has been upgraded a few times :-).
>>>>
>>>> As long as VARCHAR2 works, and it's not deprecated by Oracle, then it's
>>>> a better choice that what's recommended in the docs.
>>>>
>>>> I'd better update the docs.
>>>>
>>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

-- 
Ron Savage
http://savage.net.au/

Re: [Cgi-session-user] ORA-03124

[Junji O. <_j...@wa...>]

Hi Ron

I'm so sorry to take your time for some extra work with my fault.
I should be more careful to my words.

 > But (guessing) perhaps the app stores \x0 (null) into the session?
 > Or perhaps it stores a value which contains a control char?
It could be. I need more investigation.

I have two more questions.

1. Which do you think there is a problem of perl or Oracle?

2. ORA-03124 comes out at "$sth->fetchrow_array()" line
on CGI/Session/Driver/DBI.pm line 74
Is this your code ?
or
DBD::Oracle::st's author know a clue?
pelase see below quote

/////qw start/////
DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal
error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM
TEST_TB WHERE ID=?" with ParamValues:
:p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at
CGI/Session/Driver/DBI.pm line 74.
/////qw end/////

Sincerely,

(2013/12/19 10:51), Ron Savage wrote:
> Hi Junji
>
> Note: I'm on the mailing list, so no need to copy me personally.
>
> More below.
>
> On 19/12/13 12:12, Junji Ochi wrote:
>> Good morning Ron
>>
>> I had a screw-up.
>>
>> I said that changing the ID col data type to VARCHAR2 would be a
>> workarround.
>> but ,It doesn't matter if the ID col is VARCHAR2 or CHAR
>>
>> I tested again for you.
>> +--------+---------+--------+
>> |ID      |A_SESSION|RESULT  |
>> +--------+---------+--------+
>> |CHAR    |VARCHAR2 |NOT WORK|
>> +--------+---------+--------+
>> |VARCHAR2|VARCHAR2 |NOT WORK|
>> +--------+---------+--------+
>> |CHAR    |LONG     |WORK    |
>> +--------+---------+--------+
>> |VARCHAR2|LONG     |WORK    |
>> +--------+---------+--------+
>> |CHAR    |CLOB     |WORK    |
>> +--------+---------+--------+
>> |VARCHAR2|CLOB     |WORK    |
>> +--------+---------+--------+
>
> Thanx for doing these tests.
>
> This is of great importance because I've already patched
> CGI::Session::Driver::oracle and (my fork)
> Data::Session::Driver::Oracle, but have not released them :-)).
>
> Now I won't have to, and using git I can just roll back the code to the
> previous release :-).
>
>> It seemed VARCHAR2 on A_SESSION col caused problem.
>>
>> I have two question.
>> 1.Should we use LONG type on A_SESSION col after all?
>
> Yes. It used to work, and I've just read the Oracle docs you linked to,
> and I don't think we need worry about all the restrictions Oracle
> mentioned pertaining to long. The code only uses the long field in a
> /very/ simple way.
>
> BTW Don't forget that the id field is fixed-width. That is, once the
> program runs, all values written into the id field are the same length.
>
> So char(N) makes sense there.
>
>> 2.Could you explain why VARCHAR2 cause problem. Was the data type
>> strictly checked on A_SESSION col ?
>
> I think so. This link
> http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50956
>
> points to text which says 'To ensure proper data conversion between
> databases with different character sets, you must ensure that VARCHAR2
> data consists of well-formed strings.'. That last part, 'well-formed
> strings', is very interesting.
>
> I feel - but can't be sure - that that is what is causing the problem.
>
> I cannot find any definition of 'well-formed strings' in Oracle's docs,
> except for well-formed XML.
>
> But (guessing) perhaps the app stores \x0 (null) into the session?
> Or perhaps it stores a value which contains a control char?
>
> Cheers
> Ron
>
>> Sincerely,
>>
>>
>> (2013/12/18 15:04), Ron Savage wrote:
>>> Hi Junji
>>>
>>> See below.
>>>
>>> On 18/12/13 14:14, Junji Ochi wrote:
>>>> Hi Ron,
>>>>
>>>> Thank you for your prompt email reply.
>>>>
>>>> I changed the table definition by following The dosc.
>>>> That works fine.
>>>
>>> Excellent!
>>>
>>> And for letting us know:
>>>
>>> $many x $thanx;
>>>
>>>>     ID CHAR(40) primary key
>>>>     A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG
>>>>
>>>> But Oracle docs says not use LONG type because it is for backward
>>>> compatibility.
>>>> ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> and CLOB has some restrictions.
>>>> ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> That's why I choosed the VARCHAR2.
>>>>
>>>> A_SESSION colums must be LONG type?
>>>
>>> No I believe it does not have to be. It's just that when that code was
>>> written years ago (1st version 2005) I believed it had to be.
>>>
>>> Since then, Oracle has been upgraded a few times :-).
>>>
>>> As long as VARCHAR2 works, and it's not deprecated by Oracle, then it's
>>> a better choice that what's recommended in the docs.
>>>
>>> I'd better update the docs.
>>>
>

Re: [Cgi-session-user] ORA-03124

[Ron S. <ro...@sa...>]

Hi Junji

Note: I'm on the mailing list, so no need to copy me personally.

More below.

On 19/12/13 12:12, Junji Ochi wrote:
> Good morning Ron
>
> I had a screw-up.
>
> I said that changing the ID col data type to VARCHAR2 would be a
> workarround.
> but ,It doesn't matter if the ID col is VARCHAR2 or CHAR
>
> I tested again for you.
> +--------+---------+--------+
> |ID      |A_SESSION|RESULT  |
> +--------+---------+--------+
> |CHAR    |VARCHAR2 |NOT WORK|
> +--------+---------+--------+
> |VARCHAR2|VARCHAR2 |NOT WORK|
> +--------+---------+--------+
> |CHAR    |LONG     |WORK    |
> +--------+---------+--------+
> |VARCHAR2|LONG     |WORK    |
> +--------+---------+--------+
> |CHAR    |CLOB     |WORK    |
> +--------+---------+--------+
> |VARCHAR2|CLOB     |WORK    |
> +--------+---------+--------+

Thanx for doing these tests.

This is of great importance because I've already patched 
CGI::Session::Driver::oracle and (my fork) 
Data::Session::Driver::Oracle, but have not released them :-)).

Now I won't have to, and using git I can just roll back the code to the 
previous release :-).

> It seemed VARCHAR2 on A_SESSION col caused problem.
>
> I have two question.
> 1.Should we use LONG type on A_SESSION col after all?

Yes. It used to work, and I've just read the Oracle docs you linked to, 
and I don't think we need worry about all the restrictions Oracle 
mentioned pertaining to long. The code only uses the long field in a 
/very/ simple way.

BTW Don't forget that the id field is fixed-width. That is, once the 
program runs, all values written into the id field are the same length.

So char(N) makes sense there.

> 2.Could you explain why VARCHAR2 cause problem. Was the data type
> strictly checked on A_SESSION col ?

I think so. This link
http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF50956
points to text which says 'To ensure proper data conversion between 
databases with different character sets, you must ensure that VARCHAR2 
data consists of well-formed strings.'. That last part, 'well-formed 
strings', is very interesting.

I feel - but can't be sure - that that is what is causing the problem.

I cannot find any definition of 'well-formed strings' in Oracle's docs, 
except for well-formed XML.

But (guessing) perhaps the app stores \x0 (null) into the session?
Or perhaps it stores a value which contains a control char?

Cheers
Ron

> Sincerely,
>
>
> (2013/12/18 15:04), Ron Savage wrote:
>> Hi Junji
>>
>> See below.
>>
>> On 18/12/13 14:14, Junji Ochi wrote:
>>> Hi Ron,
>>>
>>> Thank you for your prompt email reply.
>>>
>>> I changed the table definition by following The dosc.
>>> That works fine.
>>
>> Excellent!
>>
>> And for letting us know:
>>
>> $many x $thanx;
>>
>>>     ID CHAR(40) primary key
>>>     A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG
>>>
>>> But Oracle docs says not use LONG type because it is for backward
>>> compatibility.
>>> ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201
>>>
>>>
>>>
>>>
>>> and CLOB has some restrictions.
>>> ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF
>>>
>>>
>>>
>>>
>>> That's why I choosed the VARCHAR2.
>>>
>>> A_SESSION colums must be LONG type?
>>
>> No I believe it does not have to be. It's just that when that code was
>> written years ago (1st version 2005) I believed it had to be.
>>
>> Since then, Oracle has been upgraded a few times :-).
>>
>> As long as VARCHAR2 works, and it's not deprecated by Oracle, then it's
>> a better choice that what's recommended in the docs.
>>
>> I'd better update the docs.
>>

-- 
Ron Savage
http://savage.net.au/

Re: [Cgi-session-user] ORA-03124

[Junji O. <_j...@wa...>]

Good morning Ron

I had a screw-up.

I said that changing the ID col data type to VARCHAR2 would be a 
workarround.
but ,It doesn't matter if the ID col is VARCHAR2 or CHAR

I tested again for you.
+--------+---------+--------+
|ID      |A_SESSION|RESULT  |
+--------+---------+--------+
|CHAR    |VARCHAR2 |NOT WORK|
+--------+---------+--------+
|VARCHAR2|VARCHAR2 |NOT WORK|
+--------+---------+--------+
|CHAR    |LONG     |WORK    |
+--------+---------+--------+
|VARCHAR2|LONG     |WORK    |
+--------+---------+--------+
|CHAR    |CLOB     |WORK    |
+--------+---------+--------+
|VARCHAR2|CLOB     |WORK    |
+--------+---------+--------+

It seemed VARCHAR2 on A_SESSION col caused problem.

I have two question.
1.Should we use LONG type on A_SESSION col after all?

2.Could you explain why VARCHAR2 cause problem. Was the data type
strictly checked on A_SESSION col ?

Sincerely,


(2013/12/18 15:04), Ron Savage wrote:
> Hi Junji
>
> See below.
>
> On 18/12/13 14:14, Junji Ochi wrote:
>> Hi Ron,
>>
>> Thank you for your prompt email reply.
>>
>> I changed the table definition by following The dosc.
>> That works fine.
>
> Excellent!
>
> And for letting us know:
>
> $many x $thanx;
>
>>     ID CHAR(40) primary key
>>     A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG
>>
>> But Oracle docs says not use LONG type because it is for backward
>> compatibility.
>> ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201
>>
>>
>>
>> and CLOB has some restrictions.
>> ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF
>>
>>
>>
>> That's why I choosed the VARCHAR2.
>>
>> A_SESSION colums must be LONG type?
>
> No I believe it does not have to be. It's just that when that code was
> written years ago (1st version 2005) I believed it had to be.
>
> Since then, Oracle has been upgraded a few times :-).
>
> As long as VARCHAR2 works, and it's not deprecated by Oracle, then it's
> a better choice that what's recommended in the docs.
>
> I'd better update the docs.
>

Re: [Cgi-session-user] ORA-03124

[Junji O. <_j...@wa...>]

Hi Ron,

Thank you for your prompt email reply.

I changed the table definition by following The dosc.
That works fine.

    ID CHAR(40) primary key
    A_SESSION LONG NOT NULL  #  VARCHAR2 --> LONG

But Oracle docs says not use LONG type because it is for backward 
compatibility.
ref:http://docs.oracle.com/cd/B28359_01/server.111/b28286/sql_elements001.htm#SQLRF00201

and CLOB has some restrictions.
ref:http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_data_interface.htm#CACIFCJF

That's why I choosed the VARCHAR2.

A_SESSION colums must be LONG type?

Sincerely,



(2013/12/18 9:36), Ron Savage wrote:
> Hi Junji
>
> The docs
> https://metacpan.org/pod/CGI::Session::Driver::oracle#The-sessions-table
> describe explicitly how to declare the table for Oracle.
>
> Try that and tell us how it goes.
>
> On 17/12/13 20:13, Junji Ochi wrote:
>> Dear members,
>>
>> This is my first post to cgi-session-user ML.
>> I'm a Oracle DBA in japanese company.
>>
>> My co-worker gets following error messages when using
>> CGI::Session->load() function
>> to get the CHAR type column's data from Oracle 11g R1.
>>
>> /////qw start/////
>> DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal
>> error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM
>> TEST_TB WHERE ID=?" with ParamValues:
>> :p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at
>> CGI/Session/Driver/DBI.pm line 74.
>> /////qw end/////
>>
>> 'TEST_TB' table was defined like
>>
>>      "ID" CHAR(40 BYTE)             as PRIMARY KEY
>>      "A_SESSION" VARCHAR2(4000 BYTE)
>>
>> As "CGI::Session::DBI" manual says that CAHR data type
>> is recommended for ID column.
>>
>> but , we got some workarounds here.
>>       changing table column type from 'CHAR' to 'VARCHAR2'
>>     or
>>       adding oracle's init parameter
>>     [ alter session set \"_enable_row_shipping\"=false]
>>
>> then ,everything will work fine.
>>
>> Oracle support guys said
>> " that's perl side problem, because no alert messeges in alart_log at DB
>> server side , and no ORA-03124 message between client and server by
>> taking Oracle Net trace at oracle client side.
>> but Oracle Net trace shows 'ORA-01013' just before error, which means
>> that client canceled request to query for some reasons."
>>
>> We can easily reproduce the same error without CGI::Session like ,
>>
>> //////////////
>>       $sql1 = "SELECT a_SESSION FROM TEST_TB WHERE ID=?";
>>       $sth = $dbh->prepare($sql1);
>>       $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23');
>>       $sth->execute();
>>       $sth->fetchrow_arrayref();
>> //////////////
>> then, get error ORA-03124.
>>
>> and workarround here like,
>> //////////////
>>       $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23',SQL_CHAR)
>> //////////////
>> then ,work fine.
>>
>> Is this a perl's problem or Oracle?
>>
>> Could you advise me about why this happened.
>>
>> Sincerely,
>>
>> ### CODE ###
>> #### code CGI::Session->load() ####
>> $s2 = CGI::Session->load(
>>            'driver:Oracle',
>>            '84c8aab5140cbf000a3ddaf80257b7c2695b6c23',
>>            { TableName => 'TEST_TB',
>>                    IdColName   => 'ID',
>>                    DataColName => 'a_SESSION',
>>                    Handle      => $dbh,
>>              }
>> );
>>
>> $rv =$s2->param('_SESSION_ID');
>> print "$rv \n";
>>
>>
>> ### Oracle table DDL###
>>     CREATE TABLE "TEST_TB"
>>       (    "ID" CHAR(40 BYTE),
>>        "A_SESSION" VARCHAR2(4000 BYTE) CONSTRAINT "TEST_TB_CK1" NOT
>> NULL ENABLE,
>>         CONSTRAINT "TEST_TB_PK1" PRIMARY KEY ("ID")
>>       )
>>
>> ### our lab ##
>> Oracle 11.1.0.7.12 SE RAC
>> CentOS 5.3 64bit
>>
>> perl, v5.8.8
>> 'CGI/Session.pm' => '4.42
>> 'DBI.pm' => '1.609
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Cgi-session-user mailing list
>> Cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>>
>

Re: [Cgi-session-user] ORA-03124

[Ron S. <ro...@sa...>]

Hi Junji

The docs 
https://metacpan.org/pod/CGI::Session::Driver::oracle#The-sessions-table 
describe explicitly how to declare the table for Oracle.

Try that and tell us how it goes.

On 17/12/13 20:13, Junji Ochi wrote:
> Dear members,
>
> This is my first post to cgi-session-user ML.
> I'm a Oracle DBA in japanese company.
>
> My co-worker gets following error messages when using
> CGI::Session->load() function
> to get the CHAR type column's data from Oracle 11g R1.
>
> /////qw start/////
> DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal
> error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM
> TEST_TB WHERE ID=?" with ParamValues:
> :p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at
> CGI/Session/Driver/DBI.pm line 74.
> /////qw end/////
>
> 'TEST_TB' table was defined like
>
>     "ID" CHAR(40 BYTE)             as PRIMARY KEY
>     "A_SESSION" VARCHAR2(4000 BYTE)
>
> As "CGI::Session::DBI" manual says that CAHR data type
> is recommended for ID column.
>
> but , we got some workarounds here.
>      changing table column type from 'CHAR' to 'VARCHAR2'
>    or
>      adding oracle's init parameter
>    [ alter session set \"_enable_row_shipping\"=false]
>
> then ,everything will work fine.
>
> Oracle support guys said
> " that's perl side problem, because no alert messeges in alart_log at DB
> server side , and no ORA-03124 message between client and server by
> taking Oracle Net trace at oracle client side.
> but Oracle Net trace shows 'ORA-01013' just before error, which means
> that client canceled request to query for some reasons."
>
> We can easily reproduce the same error without CGI::Session like ,
>
> //////////////
>      $sql1 = "SELECT a_SESSION FROM TEST_TB WHERE ID=?";
>      $sth = $dbh->prepare($sql1);
>      $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23');
>      $sth->execute();
>      $sth->fetchrow_arrayref();
> //////////////
> then, get error ORA-03124.
>
> and workarround here like,
> //////////////
>      $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23',SQL_CHAR)
> //////////////
> then ,work fine.
>
> Is this a perl's problem or Oracle?
>
> Could you advise me about why this happened.
>
> Sincerely,
>
> ### CODE ###
> #### code CGI::Session->load() ####
> $s2 = CGI::Session->load(
>           'driver:Oracle',
>           '84c8aab5140cbf000a3ddaf80257b7c2695b6c23',
>           { TableName => 'TEST_TB',
>                   IdColName   => 'ID',
>                   DataColName => 'a_SESSION',
>                   Handle      => $dbh,
>             }
> );
>
> $rv =$s2->param('_SESSION_ID');
> print "$rv \n";
>
>
> ### Oracle table DDL###
>    CREATE TABLE "TEST_TB"
>      (    "ID" CHAR(40 BYTE),
>       "A_SESSION" VARCHAR2(4000 BYTE) CONSTRAINT "TEST_TB_CK1" NOT
> NULL ENABLE,
>        CONSTRAINT "TEST_TB_PK1" PRIMARY KEY ("ID")
>      )
>
> ### our lab ##
> Oracle 11.1.0.7.12 SE RAC
> CentOS 5.3 64bit
>
> perl, v5.8.8
> 'CGI/Session.pm' => '4.42
> 'DBI.pm' => '1.609
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

-- 
Ron Savage
http://savage.net.au/

[Cgi-session-user] ORA-03124

[Junji O. <_j...@wa...>]

Dear members,

This is my first post to cgi-session-user ML.
I'm a Oracle DBA in japanese company.

My co-worker gets following error messages when using 
CGI::Session->load() function
to get the CHAR type column's data from Oracle 11g R1.

/////qw start/////
DBD::Oracle::st fetchrow_array failed: ORA-03124: two-task internal 
error (DBD ERROR: OCIStmtFetch) [for Statement "SELECT a_SESSION FROM 
TEST_TB WHERE ID=?" with ParamValues: 
:p1='84c8aab5140cbf000a3ddaf80257b7c2695b6c23'] at 
CGI/Session/Driver/DBI.pm line 74.
/////qw end/////

'TEST_TB' table was defined like

   "ID" CHAR(40 BYTE)             as PRIMARY KEY
   "A_SESSION" VARCHAR2(4000 BYTE)

As "CGI::Session::DBI" manual says that CAHR data type
is recommended for ID column.

but , we got some workarounds here.
    changing table column type from 'CHAR' to 'VARCHAR2'
  or
    adding oracle's init parameter
  [ alter session set \"_enable_row_shipping\"=false]

then ,everything will work fine.

Oracle support guys said
" that's perl side problem, because no alert messeges in alart_log at DB 
server side , and no ORA-03124 message between client and server by 
taking Oracle Net trace at oracle client side.
but Oracle Net trace shows 'ORA-01013' just before error, which means 
that client canceled request to query for some reasons."

We can easily reproduce the same error without CGI::Session like ,

//////////////
    $sql1 = "SELECT a_SESSION FROM TEST_TB WHERE ID=?";
    $sth = $dbh->prepare($sql1);
    $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23');
    $sth->execute();
    $sth->fetchrow_arrayref();
//////////////
then, get error ORA-03124.

and workarround here like,
//////////////
    $sth->bind_param( 1,'84c8aab5140cbf000a3ddaf80257b7c2695b6c23',SQL_CHAR)
//////////////
then ,work fine.

Is this a perl's problem or Oracle?

Could you advise me about why this happened.

Sincerely,

### CODE ###
#### code CGI::Session->load() ####
$s2 = CGI::Session->load(
         'driver:Oracle',
         '84c8aab5140cbf000a3ddaf80257b7c2695b6c23',
         { TableName => 'TEST_TB',
                 IdColName   => 'ID',
                 DataColName => 'a_SESSION',
                 Handle      => $dbh,
           }
);

$rv =$s2->param('_SESSION_ID');
print "$rv \n";


### Oracle table DDL###
  CREATE TABLE "TEST_TB"
    (    "ID" CHAR(40 BYTE),
     "A_SESSION" VARCHAR2(4000 BYTE) CONSTRAINT "TEST_TB_CK1" NOT
NULL ENABLE,
      CONSTRAINT "TEST_TB_PK1" PRIMARY KEY ("ID")
    )

### our lab ##
Oracle 11.1.0.7.12 SE RAC
CentOS 5.3 64bit

perl, v5.8.8
'CGI/Session.pm' => '4.42
'DBI.pm' => '1.609

Re: [Cgi-session-user] \t(in cleanup) Can't connect to data source '' because I can't work out

[<mim...@gm...>]

Yes, the problem was resolved by calling flush() before return(). The sub
is in a separate library file and it always work without me calling flush()
within it. Usually I commit session data to disk in my program and it was
always fine, except from yesterday.

The dev environment is a local vm box and nothing has changed as far as I'm
concern, so I wonder why cgi-session sudden change in behaviour. The only
changes I made are actually in my program. Even with that, session
continued to work without problem at first.

Anyway, thanks. Now I know better.

Cheers

Mimi


On 31 July 2013 02:06, Jeffrey Chimene <jch...@gm...> wrote:

>  On 07/30/2013 04:41 PM, mim...@gm... wrote:
>
> Issue resolved by calling flush() before returning the object. Strangely
> enough, I have being using the code for over a year without calling flush()
> anywhere within the sub and it has always worked until yesterday.
>
>
> Your hosting provider changed something. If you have a local workstation,
> did the behavior change?
> I had to disable file locking on a system that had been stable > 2 yrs.
> because of changes by the hosting provided (Rackspace)
> eval { $session = CGI::Session->new( undef, CGI->new(), { *NoFlock => 1*,
> Directory => q?../session? } ) };
>
>
>
>
>  Mimi
>
>
> On 31 July 2013 00:13, mim...@gm... <mim...@gm...> wrote:
>
>> I have CGI::Session wrapped up in the subroutine below, and this has
>> always worked.
>>
>>   sub initialise_session {
>>
>>       # Establish our database connection.
>>      my $dbh = db_connect();
>>
>>       CGI::Session->name("token");
>>      #my $session = new CGI::Session('driver:mysql;serializer:storable',
>> undef, { Handle => $dbh}) or die CGI::Session->errstr;
>>
>>          # use for purpose of testing only. Above to be used afterwards.
>>         my $session = new CGI::Session('driver:mysql', undef, { Handle =>
>> $dbh}) or die CGI::Session->errstr;
>>
>>       return $session;
>>      $session->flush();
>>      $dbh->disconnect();
>> }
>>
>>  Since yesterday it started to error and it's no longer able to commit
>> session to MySQL.
>>
>>  [Tue Jul 30 04:40:37 2013] [error] [client 192.168.0.90] \t(in cleanup)
>> Can't connect to data source '' because I can't work out what driver to use
>> (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env
>> var is not set) at /usr/local/share/perl5/CGI/Session/Driver/DBI.pm line
>> 26, referer: http://localhost/user.html
>>
>>  No changes have been made to the subroutine, so I'm wondering why this
>> sudden error. As you can see above, I have called flush() to commit the
>> session before the db is connected. I also did the same else where in my
>> program, but the error persist.
>>
>>  Any ideas?
>>
>>  Thanks
>>
>>  Mimi
>>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Cgi-session-user mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>

Re: [Cgi-session-user] \t(in cleanup) Can't connect to data source '' because I can't work out

[Jeffrey C. <jch...@gm...>]

On 07/30/2013 04:41 PM, mim...@gm... wrote:
> Issue resolved by calling flush() before returning the object.
> Strangely enough, I have being using the code for over a year without
> calling flush() anywhere within the sub and it has always worked until
> yesterday.

Your hosting provider changed something. If you have a local
workstation, did the behavior change?
I had to disable file locking on a system that had been stable > 2 yrs.
because of changes by the hosting provided (Rackspace)
eval { $session = CGI::Session->new( undef, CGI->new(), { *NoFlock =>
1*, Directory => q?../session? } ) };
>
>
>
> Mimi
>
>
> On 31 July 2013 00:13, mim...@gm... <mailto:mim...@gm...>
> <mim...@gm... <mailto:mim...@gm...>> wrote:
>
>     I have CGI::Session wrapped up in the subroutine below, and this
>     has always worked.  
>
>     sub initialise_session {
>
>          # Establish our database connection.
>          my $dbh = db_connect();
>
>          CGI::Session->name("token");
>          #my $session = new
>     CGI::Session('driver:mysql;serializer:storable', undef, { Handle
>     => $dbh}) or die CGI::Session->errstr;
>
>             # use for purpose of testing only. Above to be used
>     afterwards.
>             my $session = new CGI::Session('driver:mysql', undef, {
>     Handle => $dbh}) or die CGI::Session->errstr;
>
>          return $session;
>          $session->flush();
>          $dbh->disconnect();
>     }
>
>     Since yesterday it started to error and it's no longer able to
>     commit session to MySQL.
>
>     [Tue Jul 30 04:40:37 2013] [error] [client 192.168.0.90] \t(in
>     cleanup) Can't connect to data source '' because I can't work out
>     what driver to use (it doesn't seem to contain a 'dbi:driver:'
>     prefix and the DBI_DRIVER env var is not set) at
>     /usr/local/share/perl5/CGI/Session/Driver/DBI.pm line 26, referer:
>     http://localhost/user.html
>
>     No changes have been made to the subroutine, so I'm wondering why
>     this sudden error. As you can see above, I have called flush() to
>     commit the session before the db is connected. I also did the same
>     else where in my program, but the error persist.
>
>     Any ideas?
>
>     Thanks
>
>     Mimi
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] \t(in cleanup) Can't connect to data source '' because I can't work out

[<mim...@gm...>]

Issue resolved by calling flush() before returning the object. Strangely
enough, I have being using the code for over a year without calling flush()
anywhere within the sub and it has always worked until yesterday.



Mimi


On 31 July 2013 00:13, mim...@gm... <mim...@gm...> wrote:

> I have CGI::Session wrapped up in the subroutine below, and this has
> always worked.
>
> sub initialise_session {
>
>      # Establish our database connection.
>      my $dbh = db_connect();
>
>      CGI::Session->name("token");
>      #my $session = new CGI::Session('driver:mysql;serializer:storable',
> undef, { Handle => $dbh}) or die CGI::Session->errstr;
>
>         # use for purpose of testing only. Above to be used afterwards.
>         my $session = new CGI::Session('driver:mysql', undef, { Handle =>
> $dbh}) or die CGI::Session->errstr;
>
>      return $session;
>      $session->flush();
>      $dbh->disconnect();
> }
>
> Since yesterday it started to error and it's no longer able to commit
> session to MySQL.
>
> [Tue Jul 30 04:40:37 2013] [error] [client 192.168.0.90] \t(in cleanup)
> Can't connect to data source '' because I can't work out what driver to use
> (it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env
> var is not set) at /usr/local/share/perl5/CGI/Session/Driver/DBI.pm line
> 26, referer: http://localhost/user.html
>
> No changes have been made to the subroutine, so I'm wondering why this
> sudden error. As you can see above, I have called flush() to commit the
> session before the db is connected. I also did the same else where in my
> program, but the error persist.
>
> Any ideas?
>
> Thanks
>
> Mimi
>

[Cgi-session-user] \t(in cleanup) Can't connect to data source '' because I can't work out

[<mim...@gm...>]

I have CGI::Session wrapped up in the subroutine below, and this has always
worked.

sub initialise_session {

     # Establish our database connection.
     my $dbh = db_connect();

     CGI::Session->name("token");
     #my $session = new CGI::Session('driver:mysql;serializer:storable',
undef, { Handle => $dbh}) or die CGI::Session->errstr;

        # use for purpose of testing only. Above to be used afterwards.
        my $session = new CGI::Session('driver:mysql', undef, { Handle =>
$dbh}) or die CGI::Session->errstr;

     return $session;
     $session->flush();
     $dbh->disconnect();
}

Since yesterday it started to error and it's no longer able to commit
session to MySQL.

[Tue Jul 30 04:40:37 2013] [error] [client 192.168.0.90] \t(in cleanup)
Can't connect to data source '' because I can't work out what driver to use
(it doesn't seem to contain a 'dbi:driver:' prefix and the DBI_DRIVER env
var is not set) at /usr/local/share/perl5/CGI/Session/Driver/DBI.pm line
26, referer: http://localhost/user.html

No changes have been made to the subroutine, so I'm wondering why this
sudden error. As you can see above, I have called flush() to commit the
session before the db is connected. I also did the same else where in my
program, but the error persist.

Any ideas?

Thanks

Mimi

Re: [Cgi-session-user] Active Sessions on Server?

[Mark S. <ma...@su...>]

Martin,

> 1.)
> 
> is there a nice way to detect all active sessions on the webserver 
> from within the cgi-script?
> 
> i would like to implement a small "who's online" feature. it would be 
> possible to store each user
> activity with a timestamp on the server and take a look at it with 
> the eye on the auto-session-timeout
> time, but maybe there's a better way directly with cgi::session itself?

If you use a SQL driver, then you can easily query the database. I
recommend using SQL driver.

> 2.)
> 
> all the sessions that expired on the server aren't removed from the 
> given directory, do you know a nice
> way to detect and delete all expired session files on the server.

Consider CGI::Session::ExpireSessions

http://search.cpan.org/perldoc?CGI::Session::ExpireSessions

    Mark