Hello M.
I'll try to answer your question, but there's not a lot of detail there
about the business problem you are trying to solve.
Muckeypuck said:
Lets say i had two classes, user and customer that represented tables in
the database with 7 or 8 fields max. Lets say that instead of passing an
id around hitting my database any time i needed information from those 2
tables, i just made those two classes serializable and passed them around
in a session object.
Is this a good idea? Is it scalable if the app were to host 1000000's of
users at once? Will it perform well?
There is nothing wrong with using the Data Transfer Object pattern to move
data around. Keeping a bit of data in the session is essentially the same
as placing it in a cache object that you can access later.
Normally, you want to place things in the cache that ALL of your customers
can use. For example, let's say that you have a set of canned reports that
you can make available to your customers. Keeping the names of the reports
in the cache is useful because you may need to fill a navigation list or
drop-down box in 100 page requests in the same second and making a bunch of
database requests may not be terribly efficient.
On the other hand, if you place things in the cache that are likely to be
specific to the user on your site, you run the risk of blowing your cache up
to a very large size. That will CERTAINLY affect throughput. Realize that
the session object tends to hang around a while after the user has actually
left, so if you have 60,000 users per hour, you need to be able to hold data
for 20,000 of them at a time.
You also have the problem of making your session objects available across a
web farm. (at the rate of 60K users per hour, you will have a LOT of web
servers). Realize what this means... the web server servicing the request
does not actually have the session object. It has to contact another server
to get it. That other server has to use an ID to look it up. If there is a
lot of data in the cache, it will store things on a hard drive in a system
known for fast lookup (like, for example, SQL Server). The data will be
found and transmitted across your internal network back to the web server.
Sounds like a db lookup, doesn't it? Not really a good tradeoff to try to
avoid hitting a database by putting things into a cache that is backed up by
a database.
In a normally stateless environment, it is rare to see the need for placing
a customer or user object in the session. I'd leave the data in the
database between requests. No harm in bringing the data into a singleton
during the request processing, so that multiple classes can access it.
Wouldn't use the session for that, though.
I hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
