My apologies to David then... I think you are right. Maybe I ought to look
at those books :)
-tg
----- Original Message -----
From: Dustin Aleksiuk <[EMAIL PROTECTED]>
To: Taylor Gautier <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, November 04, 1999 1:28 PM
Subject: Re: Re: Session values question
> Actually, a classic hash table has to store the keys because of collision.
> Unless you have a perfect hashing algorithm, occasionally two keys will
> map to the same address. You implement some sort of collision resolution
> scheme, and store the keys so you know which value to get out.
>
> The storage of keys is transparent to the user of the Hash Table.
>
> I hope I'm right about this (I'm pretty sure I am).
>
> :)
>
> Dustin Aleksiuk
>
>
> ----- Original Message -----
> From: Taylor Gautier <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, November 04, 1999 11:56 AM
> Subject: Re: Session values question
>
>
> > 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
>
>
===========================================================================
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
