You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2004/03/10 10:40:09 UTC
Re: Session Quesions/Comments
Tom Krehbiel <to...@motorola.com> writes:
> Locking might be a good idea but I can't think of any case where a
> session would conflict with itself, unless the session key was
> corrupted. Session clean up (when a session goes away) is a problem
> that has to be dealt with but it's a problem with databases too.
I guess you and Karl are right... but... couldn't multiple Apache
instances both be trying to update the session at the same time, and
run into problems trying to write to the file?
Any progress writing a Session backend for files?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Karl Lehenbauer <ka...@sc.com> writes:
> I've started looking at it. It's a little depressing. There aren't
> a whole lot of places where DIO is called, so at least that's a
> relief. But, you know, it's so clean with SQL and then to do it
> with files, it's got to all be handled explicitly, like a pre-SQL
> 1970s COBOL program or something. And there's the issue of
> rewriting the file when a new variable is added, or having multiple
> files in a directory (I'm talking about cached session data), etc.
Well how about using SQLlite? I think it's under a BSD license,
meaning we can redistribute it. I think it in turn uses text files or
something as a backend, but at least you wouldn't have to tweak the
interface so much.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Damon Courtney <da...@your.unreality.com>.
> This is a terrific idea. This would make stuff like "DIO store" and
> "DIO fetch" work. I assume it wouldn't be able to do "delete from
> session_cache_table where timestamp 'now' - session_update_time >
> interval '7200 seconds';"
Hrmm... There is a 'DIO delete' command, but it's pretty specific.
I wonder if we could make it a little better. Hrmm...
>
> > MySQL support should work just fine. I've used DIO under MySQL
> > on a few different projects, and it should be pretty functional.
> >
> I didn't mean to imply that the MySQL support was questionable, 'cuz I
> knew it was solid. What I meant to say was that sessions haven't been
> tested with MySQL, and that there might be a subtle difference in the
> SQL required to get things like the delete statement above to work vis
> a vis Postgresql.
Well, it's a little questionable since I only used it a few times,
and Andy's the only one who's used it in any real capacity. But, he
hasn't complained to me about any bugs, so it should be pretty solid.
All I ever use is Postgres, so I don't know. 0-]
I'm not sure how well the query will work in MySQL. I think that's
the major crux of abstracting a SQL class to the point where you can
truly switch databases completely without rewriting code. I don't
think we'll ever reach that point, but we can sure come damn close.
We're all pretty clever guys and some damn smart programmers.
We can come up with something. Maybe the delete command could be
extended to use the same criteria as the search command, and it would
delete all matching items from a search result. I dunno'... I'd love
it if all the basic commands (fetch, store, delete) could be truly
useful without having to use any SQL code.
Any ideas?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
On Mar 10, 2004, at 10:53 AM, Damon Courtney wrote:
> I was actually just going to write up a DIO class to handle flat
> text files. That way, things like this wouldn't need enhancements.
> They
> just use DIO and pick the database type. It shouldn't be that tough.
> I've written several before.
This is a terrific idea. This would make stuff like "DIO store" and
"DIO fetch" work. I assume it wouldn't be able to do "delete from
session_cache_table where timestamp 'now' - session_update_time >
interval '7200 seconds';"
> MySQL support should work just fine. I've used DIO under MySQL
> on a few different projects, and it should be pretty functional.
>
I didn't mean to imply that the MySQL support was questionable, 'cuz I
knew it was solid. What I meant to say was that sessions haven't been
tested with MySQL, and that there might be a subtle difference in the
SQL required to get things like the delete statement above to work vis
a vis Postgresql.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Damon Courtney <da...@your.unreality.com>.
> I've started looking at it. It's a little depressing. There aren't a
> whole lot of places where DIO is called, so at least that's a relief.
> But, you know, it's so clean with SQL and then to do it with files,
> it's got to all be handled explicitly, like a pre-SQL 1970s COBOL
> program or something. And there's the issue of rewriting the file when
> a new variable is added, or having multiple files in a directory (I'm
> talking about cached session data), etc.
>
> I'm toying with the idea of creating a new class that simply manages
> the storage for sessions. That way no ugliness would creep into the
> session class itself, which right now is not ugly at all, at least in
> my opinion. Yeah, I think that's the ticket.
I was actually just going to write up a DIO class to handle flat
text files. That way, things like this wouldn't need enhancements. They
just use DIO and pick the database type. It shouldn't be that tough.
I've written several before.
> One small additional thing, since DIO provides a certain degree of
> abstraction among different database servers, it should be very easy to
> make sessions support MySQL. Sessions may actually work with MySQL
> with no changes at all.
MySQL support should work just fine. I've used DIO under MySQL
on a few different projects, and it should be pretty functional.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
On Mar 10, 2004, at 3:40 AM, David N. Welton wrote:
> Any progress writing a Session backend for files?
Hi Everyone,
I've started looking at it. It's a little depressing. There aren't a
whole lot of places where DIO is called, so at least that's a relief.
But, you know, it's so clean with SQL and then to do it with files,
it's got to all be handled explicitly, like a pre-SQL 1970s COBOL
program or something. And there's the issue of rewriting the file when
a new variable is added, or having multiple files in a directory (I'm
talking about cached session data), etc.
I'm toying with the idea of creating a new class that simply manages
the storage for sessions. That way no ugliness would creep into the
session class itself, which right now is not ugly at all, at least in
my opinion. Yeah, I think that's the ticket.
I'm going out of town tomorrow and won't be back until early next week.
Pretty much zero chance I'll get to work on it before then.
One small additional thing, since DIO provides a certain degree of
abstraction among different database servers, it should be very easy to
make sessions support MySQL. Sessions may actually work with MySQL
with no changes at all.
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
David,
> Tom Krehbiel <to...@motorola.com> writes:
>
>>Locking might be a good idea but I can't think of any case where a
>>session would conflict with itself, unless the session key was
>>corrupted. Session clean up (when a session goes away) is a problem
>>that has to be dealt with but it's a problem with databases too.
>
> I guess you and Karl are right... but... couldn't multiple Apache
> instances both be trying to update the session at the same time, and
> run into problems trying to write to the file?
>
> Any progress writing a Session backend for files?
I can't give a definitive answerer because I don't have an in depth
understanding of all the ways browsers and Apache can be configured
and operate. My understanding is that a session (at least in PHP) is
bound to the connection parameters (i.e. a single instance of a browser).
As long as a single instance of a browser only talks on one channel
there shouldn't be any locking problems because the channel will only
be serviced by a single Apache instance at any given instance (at least
that's what I would expect).
Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org