>>and does this mean that trying to store lots and lots of
>>really big things simultaneously as session objects could lead
>>to bad consequences, like the
>>serlet engine or entire server going down?
>No, you're next point covers this.
>Explanation: You only put references in the session.
>This ensures the data hangs around but the server is only going to
>"go down" if you run out of memory. Even then a good servlet engine
>should just carry on and either GC or let the servlets know that
>they've run out of memory (ie: throw OutOfMemoryException a lot).
Ok, I should have been more careful in the way I said it up there.
The question is: given that the data that's stored via session
objects hangs around in memory for some period of time, and if
you have a lot of invocations of servlet(s) happening in a short
period of time, all creating lots and lots of data and storing
it all in session objects, it's possible to fill up whatever (or
whose ever) memory is being used to store that data. Whether this
is likely to happen in some given scenerio is a different question.
Also, the particular consequences of that happening (server going
down, JVM locking up, servlets getting OutOfMemoryException,
whatever) is yet another question. But the bottom line is that if
one is looking at storing some pretty massive things in session
objects, and one is looking at a possible scenerio of lots of these
things being created over a relatively short period of time, one
needs to address the possibility of running out of memory.
My purpose here is to make sure that I have at least some grasp
of the differences between servlet programming and "ordinary"
programming. An instance of a servlet can actually have many
invocations, and each of those can contribute to overall memory
usage. And, when dealing with the Web, you're talking about
potentially hundreds (thousands?) of more or less simultaneous
invocations. So while in the writing of a non-servlet you
wouldn't give a thought to keeping a couple of megs of data
around, those same couple of megs could multiply into a few
hundred megs in a servlet engine, right?
>>On the upside, is it the case that storing and retrieving
>>session objects is low-overhead because it's basically just
>>passing pointers back and forth?
>Yes. Not pointers, references. Java not C.
(Darn these nit-picking engineers :-) Whatever. I just wanted to
make sure that the "obvious" answer, i.e. that the entire object
was not copied from where the servlet created it to where the
session object stored it and back again, was indeed correct. You
know what they say about assuming...
>There are no inherant trade offs.
>But I suspect you are going to need more data with lots of servlets
>to distinguish which MassiveObject to load.
Why? If the init parameters for each name/alias indicate which
MassiveObject to load, why would anything else be needed? The init
method would need a switch, or would need to construct a string
for the appropriate file name or database query, but that's it.
>I think you're getting worried with no reason about big objects.
>Think about fairly sizable file caches, they are done quite a lot
>with servlets (ie: cache a whole web site).
Well, I wasn't really "worried", I just wanted to see if there
were any significant problems with having servlets that used
huge amounts of data storage, and what the tradeoffs might be
in the two approaches that I outlined.
>It is still better to have 1 servlet for 1 type of request however.
>Apart from anything it's tidier.
>And who is going to load and map all these servlets?
Ok, now I'm not sure which if my two possibilities you're saying
is better. You're advocating the one servlet with an array of
MassiveObjects approach? I'm not so sure that's better. Using
the model of one "conceptual" servlet per MassiveObject makes
the code cleaner. No array or vector to deal with, no need to
keep around an index that holds which array element I'm using.
The init method reads the init parameter, loads the corresponding
MassiveObject, and the entire rest of the code of the servlet
just deals with the MassiveObject directly. I mean, in the
servlet.properties file (or equivalent), would be a lot of
lines like this:
servlet.myservlet1.code=MyServlet
servlet.myservlet1.initArgs=whichfile=file1
servlet.myservlet2.code=MyServlet
servlet.myservlet2.initArgs=whichfile=file2
servlet.myservlet3.code=MyServlet
servlet.myservlet3.initArgs=whichfile=file3
And, given that it sounds like you're saying that there's no
significant performance difference between the two approaches,
this way seems more elegant.
In any case, thanks muchly for your response!
--Jim Preston
InterSurvey Inc.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
