I'm currently working on the architecture for a new build of an old site.
I'm trying to avoid using session variables on the understanding that they
are the work of the devil. Having previously rolled my own session
management on other projects, I'd like to avoid all the hassle of having to
pass sessionids around on the querystring. So how does this sound for a
hybrid solution?

I'm thinking of leaving the IIS session management switched on. Let IIS hand
out a sessionid and set the cookie. I would then use this sessionid as a key
in a simple id/name/value table in a SQL Server 2000 database. Then - and
this is where it gets daft - on every page I'd load all the data into a
page-scope dictionary object. The dictionary could then be read and written
to on the page, and at the end I'd need to write it all back to the
database.When the session expires, the user gets disconnected from their
data and I can clean up the database. I will already be using a database
connection for every page.

Am I crazy?

To me this seems like a good approach if dealing with a whole stack of data
that needs to be carried in the session. However, most of the time I'm
probably looking at about half a dozen short strings. Am I just creating
something that will be less efficient than the inefficient session variables
I am trying to avoid?

Any better suggestions for replacing session variables without having to
manually carry a sessionid around the site?

Thanks!

Drew

Re: Architecture: avoiding sessions by Ken

Ken
Mon Sep 15 05:18:11 CDT 2003

a) Will this app need to be ported to some other platform (eg ASP.Net etc),
and will parts of it need to run concurrently with ported parts?
b) Will it be possible that this application will ever need to run on some
kind of server farm?
c) Will you be able to reuse your code in other applications?

If you can't answer "yes" to any of the above, then I don't think that the
effort or rolling your own session state system is worth it. Judicious use
of ASP Session variables is fine. Problems seem to come in when:
a) people store inappropriate objects in session scope (like ADO
Connections)
b) people store vast amounts of data in session scope that really has
nothing to do with a session (which instead could be stored in cookies, or
in the case of a multi-page form, in hidden input fields)
c) people answer "yes" to one of the above questions, especially (a) or (b),
but go with ASPSession state anyway.

Cheers
Ken

"DrewM" <bogus@doesntexist.com> wrote in message
news:uyNkI%232eDHA.2260@TK2MSFTNGP10.phx.gbl...
: I'm currently working on the architecture for a new build of an old site.
: I'm trying to avoid using session variables on the understanding that they
: are the work of the devil. Having previously rolled my own session
: management on other projects, I'd like to avoid all the hassle of having
to
: pass sessionids around on the querystring. So how does this sound for a
: hybrid solution?
:
: I'm thinking of leaving the IIS session management switched on. Let IIS
hand
: out a sessionid and set the cookie. I would then use this sessionid as a
key
: in a simple id/name/value table in a SQL Server 2000 database. Then - and
: this is where it gets daft - on every page I'd load all the data into a
: page-scope dictionary object. The dictionary could then be read and
written
: to on the page, and at the end I'd need to write it all back to the
: database.When the session expires, the user gets disconnected from their
: data and I can clean up the database. I will already be using a database
: connection for every page.
:
: Am I crazy?
:
: To me this seems like a good approach if dealing with a whole stack of
data
: that needs to be carried in the session. However, most of the time I'm
: probably looking at about half a dozen short strings. Am I just creating
: something that will be less efficient than the inefficient session
variables
: I am trying to avoid?
:
: Any better suggestions for replacing session variables without having to
: manually carry a sessionid around the site?
:
: Thanks!
:
: Drew
:
:



Re: Architecture: avoiding sessions by DrewM

DrewM
Mon Sep 15 06:52:09 CDT 2003

"Ken Schaefer" wrote:

> a) Will this app need to be ported to some other platform (eg ASP.Net
etc),
> and will parts of it need to run concurrently with ported parts?
> b) Will it be possible that this application will ever need to run on some
> kind of server farm?
> c) Will you be able to reuse your code in other applications?
>
> If you can't answer "yes" to any of the above, then I don't think that the
> effort or rolling your own session state system is worth it.

Thanks Ken.

(a) is possible, although in this scenario I think we would end up needing
to re-engineer the framework anyway, so I'm not concerned.

(b) is very unlikely, as our application has a finite, measured audience. To
be honest, if load was a problem we could get a bigger server. We're
probably looking at max 30 concurrent sessions at any one time. That said, I
want to be as efficient as possible - no reason to be sloppy just because I
could get away with it.

(c) our code is designed to be reusable - but within the same site
framework.

On balance, it looks like it might be a waste of time rolling my own.
Perhaps what I'll do is try to find a middle ground - storing as little data
possible in session variables - maybe just a user id as standard.

Thanks for the input .. it's one of those moments where you have to live and
work with the decision you make for a long time, so it helps to get outside
opinions :-)

Drew



Re: Architecture: avoiding sessions by Tom

Tom
Mon Sep 15 08:21:54 CDT 2003

Based on your comments below, there's no reason to avoid the use of session
vars (given the caveats stated by Ken).

--
Tom Kaminski IIS MVP
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://mvp.support.microsoft.com/
http://www.microsoft.com/windowsserver2003/community/centers/iis/

"DrewM" <bogus@doesntexist.com> wrote in message
news:OOym873eDHA.560@tk2msftngp13.phx.gbl...
> "Ken Schaefer" wrote:
>
> > a) Will this app need to be ported to some other platform (eg ASP.Net
> etc),
> > and will parts of it need to run concurrently with ported parts?
> > b) Will it be possible that this application will ever need to run on
some
> > kind of server farm?
> > c) Will you be able to reuse your code in other applications?
> >
> > If you can't answer "yes" to any of the above, then I don't think that
the
> > effort or rolling your own session state system is worth it.
>
> Thanks Ken.
>
> (a) is possible, although in this scenario I think we would end up needing
> to re-engineer the framework anyway, so I'm not concerned.
>
> (b) is very unlikely, as our application has a finite, measured audience.
To
> be honest, if load was a problem we could get a bigger server. We're
> probably looking at max 30 concurrent sessions at any one time. That said,
I
> want to be as efficient as possible - no reason to be sloppy just because
I
> could get away with it.
>
> (c) our code is designed to be reusable - but within the same site
> framework.
>
> On balance, it looks like it might be a waste of time rolling my own.
> Perhaps what I'll do is try to find a middle ground - storing as little
data
> possible in session variables - maybe just a user id as standard.
>
> Thanks for the input .. it's one of those moments where you have to live
and
> work with the decision you make for a long time, so it helps to get
outside
> opinions :-)
>
> Drew
>
>



Re: Architecture: avoiding sessions by Mark

Mark
Mon Sep 15 15:38:15 CDT 2003

I'd agree with Tom.

But if you absolutely insist, you don't need to use a dictionary object at
page level. Just put the values into the session object at the start of the
page and do a session.abandon at the end.

--
Mark Schupp
--
Head of Development
Integrity eLearning
Online Learning Solutions Provider
mschupp@ielearning.com
http://www.ielearning.com
714.637.9480 x17


"Tom Kaminski [MVP]" <tomk (A@T) mvps (D.O.T) org> wrote in message
news:bk4e9g$cqv2@kcweb01.netnews.att.com...
> Based on your comments below, there's no reason to avoid the use of
session
> vars (given the caveats stated by Ken).
>
> --
> Tom Kaminski IIS MVP
> http://www.iistoolshed.com/ - tools, scripts, and utilities for running
IIS
> http://mvp.support.microsoft.com/
> http://www.microsoft.com/windowsserver2003/community/centers/iis/
>
> "DrewM" <bogus@doesntexist.com> wrote in message
> news:OOym873eDHA.560@tk2msftngp13.phx.gbl...
> > "Ken Schaefer" wrote:
> >
> > > a) Will this app need to be ported to some other platform (eg ASP.Net
> > etc),
> > > and will parts of it need to run concurrently with ported parts?
> > > b) Will it be possible that this application will ever need to run on
> some
> > > kind of server farm?
> > > c) Will you be able to reuse your code in other applications?
> > >
> > > If you can't answer "yes" to any of the above, then I don't think that
> the
> > > effort or rolling your own session state system is worth it.
> >
> > Thanks Ken.
> >
> > (a) is possible, although in this scenario I think we would end up
needing
> > to re-engineer the framework anyway, so I'm not concerned.
> >
> > (b) is very unlikely, as our application has a finite, measured
audience.
> To
> > be honest, if load was a problem we could get a bigger server. We're
> > probably looking at max 30 concurrent sessions at any one time. That
said,
> I
> > want to be as efficient as possible - no reason to be sloppy just
because
> I
> > could get away with it.
> >
> > (c) our code is designed to be reusable - but within the same site
> > framework.
> >
> > On balance, it looks like it might be a waste of time rolling my own.
> > Perhaps what I'll do is try to find a middle ground - storing as little
> data
> > possible in session variables - maybe just a user id as standard.
> >
> > Thanks for the input .. it's one of those moments where you have to live
> and
> > work with the decision you make for a long time, so it helps to get
> outside
> > opinions :-)
> >
> > Drew
> >
> >
>
>



Re: Architecture: avoiding sessions by dlbjr

dlbjr
Mon Sep 15 17:56:16 CDT 2003

Drew,

If your rebuilding, check out ASP.NET. It will do all this for you.

-dlbjr

invariable unerring alien



Re: Architecture: avoiding sessions by DrewM

DrewM
Tue Sep 16 05:59:22 CDT 2003

"dlbjr" <dontknow@do.u> wrote:

> If your rebuilding, check out ASP.NET. It will do all this for you.

I'd love to rebuild in ASP.NET, but we have too many legacy modules which
are too expensive to rebuild from scratch. The more I try to do things
'properly' in ASP, the more frustrated I get with it :-(

Thanks for all the input, guys.

Drew