RE: [Cgi-session-user] Trouble with C::S::SQLite

[Sherzod R. <she...@ha...>]

> My most recent thinking on this is that we should add a "auto_flush"
option, which would currently default to false.

Since auto-flush isn't working for everybody, and since I'm not too sure
about having to call flush() manually, why don't we just synchronize at
each change made to the object? For those who have never had trouble
with auto-flush feature, we'll make it optional.

So here is what I'm proposing. When one does:

	$session->param('name', 'John Doe');

flush() would get called automatically from within param(), because a
change has been made to the object, and so for each method/activity that
changes the data table. I admit, it will not be very efficient when
param() is called many times during a particular instance of a program.
Even if param() is called just once, the object would still have to be
synchronized at least twice, first to update the atime(), and second to
update the data.

Having to update multiple keys at once should not be much concern
either, because param() method currently provides (I think, althought
may not be tested :) ) a way of updating multiple keys at batch,
reducing number of disk accesses), as in:

	$session->param(	key1	=> 'value1',
					key2	=> 'value2',
					#...
				);

This way CGI::Session will no longer rely on DESTORY().

For those who never had trouble with auto-flush feature, and for those
who don't mind having to call flush() manually, we'll provide
delay_flush() feature, which, if turned on, will delay flush() until the
object instance is destroyed, which is the current behavior, and the one
found not reliable for many. The proposed syntax may be one or all of:

	CGI::Session->delay_flush( 1 );
	# or
	$session->delay_flush( 1 );
	# or
	$session = CGI::Session->new(undef, undef, {delay_flush=>1});

We could construct some benchmark tests, with and without delay_flush().
If the difference in speed isn't much, we may not even need
delay_flush().

Any ideas?

--  
Sherzod Ruzmetov