You're both wrong :)
David is half right. A session implements it's storage using a hashtable.
A hashtable does not store the keys, that's why it's called a *HASH*table.
It stores the values in a data structure. The keys, when a request for a
value is made, are converted into a hashcode which is a lookup index into
the datastructure. It's a bit more complex than this, if you're interested
take some college classes or read a book :)
The values are stored at approximately 2*the number of characters (because
of Unicode, as David points out), so David is right there.
For large amounts of strings you could probably throw away the size of the
hashtable in your calculation, and you can just use part of David's
equation, if you want you could make some_fudge_factor be some value that
represents the Hashtable's usage. I haven't researched Java's
implementation, it may actually vary over time as more or less items are
stored in it:
num_bytes = [75 * (avg_value_size) * 2] * + some_fudge_factor;
Sameer, I know what you're trying to say, but I think you missed the point.
Yes, objects are compiled and then take up some amount of space in memory
(less than the text file that described them, hopefully). But that is not
usually their entire memory usage, because if they point to Strings or
Hashtables you have to walk the graph to see how much each part is taking
up. In this case, the original poster was concerned with the simultaneous
storage of many form fields, so the total space used is important, not the
part contributed by the actual object.
-taylor
----- Original Message -----
From: Sameer Tyagi <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, November 04, 1999 7:53 AM
Subject: Re: Session values question
> The misconception is that the object IS NOT stored in the session. ITS A
> HANDLE or reference. The actual object is in memory.
> This math that you show is totally incorrect, Its like saying that the
> each charecter in ASCII is 1 byte so if your source file contains 2000
> charecters of source code the compiled class file will be 8*2000 bytes.
> HUHH ??
> The actual object storeage in a session doesnt involve more than a few
> bytes.!~
>
> The same thing happens when you store stuff in a Hashtable, a ref is
> stored NOT the object ~!!! THERE is a BIG
> difference and most C/C++ programmers have difficulty understanding that
> in Java,objects( not in RMI) are passed by reference and primitives by
> values.
>
> I have enclosed a test program for you . That puts
> >java -Xms32M -Xmx32M Mem
>
> This populates the Hashtable with 10000 MyObjects
> As you can see, each object translates into 158.4832 bytes ( not KB)
>
> The actual session memory usage depends on the servers implememntation
> of the HttpSession inteface. weblogic for example uses EJBs to
> internally handle sessions, as compared to the Suns JSWDK.
>
> Hope this helps.
> -Sameer
>
>
>
> David Chisholm wrote:
> >
> > You're right that the session values are stored in the server, and I
think a
> > bean is a very convenient way to store these values, but I suggest that
you
> > do the math to determine whether this is consuming two much memory:
> >
> > num_bytes = [75 * (avg_field_name_size) * 2] + [75 * (avg_value_size) *
2] *
> > expected_number_of_concurrent_users;
> >
> > (The *2 is because Java characters are 2 byte Unicode characters)
> >
> > The numbers can quickly add up. Then of course you can start looking for
> > ways to reduce this cost. For instance, the field names are always the
> > same, so do you have to store them in every bean or can they be static
class
> > data? Can you number the fields rather than using a label and then use
the
> > number for the HTML element's ID value? If the form history isn't
> > frequently used, is it more efficient to persist the form values into a
> > temporary file that's associated with the session?
> >
> > My .02,
> > David
> >
> > > -----Original Message-----
> > > From: A mailing list about Java Server Pages specification and
reference
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Medcraft
> > > Sent: Thursday, November 04, 1999 4:53 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Session values question
> > >
> > >
> > > I need to store form field values from a fairly large form (75 fields)
so
> > > that later forms can be prepopulated. I have written a Bean that
> > > uses a two
> > > dimensional array of Strings to hold field names and values.
> > >
> > > This works well, but I am unsure how it will affect server
> > > performance when
> > > accessed by a lot of users concurrently. Am I right in thinking
> > > that session
> > > values are stored in the Server's memory?
> > >
> > > Also, I know I could simply have written the field names & values
directly
> > > to the Session Object rather than writing the Bean. Is there much
> > > difference
> > > apart from adding an unnecessary component? (I went for the Bean
> > > as I hadn't
> > > used one before and wante to try it out.)
> > >
> > > Thanks,
> > >
> > > Paul
> > >
> > > ==================================================================
> > > =========
> > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> > > JSP-INTEREST".
> > > FAQs on JSP can be found at:
> > > http://java.sun.com/products/jsp/faq.html
> > > http://www.esperanto.org.nz/jsp/jspfaq.html
> > >
> >
> >
===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> > FAQs on JSP can be found at:
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
