"Juan M. Gargiulo" wrote:
> Craig:
>
> First, thanks for your comments, they are vey useful.
>
> Second, I've two questions in relation to the solution you propose for
> session security.
>
> -Does the creation of a new bean for every session impacts on performance?
A bean that you store in a session is just like any other Java object -- it's
impact is dependent on how complex the object is. For simple beans that just
store a username and a couple other properties, you'll never see it. Remember,
this bean only gets created when you log on (a one-time event), so even a
multi-second initialization (looking up the user in a database and storing some
in-memory information about him/her) is not particularly painful.
Regarding the basic overhead of creating objects, Java is pretty good at this. If
you were to look at the inside of the way a servlet engine processes your
requests, you'll probably find in the range of 10 - 100 new object creations
happening on every request anyway, plus whatever your servlet does.
Regarding access to the beans after they are created, you can assume that the
servlet engine uses a Hashtable or something faster to store the user objects you
put there. Therefore, the servlet engine can grab objects (based on the key) back
out just as fast as you can out of a Hashtable in your own code.
>
> -Do you think is a good idea to rely on this solution for keeping user
> information in the session?
>
Short answer: yes.
Longer answer #1: Well, what else are you going to do? The HTTP protocol is
stateless -- in other words, there is no built in way for the servlet engine to
know that this request is connected to the previous one from the same client. The
session management capabilities of the servlet API (which are also used for JSPs)
was designed to make this as easy as possible to program for. Besides keeping
track of what the servlet engine itself needs (the session id, the last accessed
time, and so on), the HttpSession object lets you store your own stuff. The
LoginBean that I proposed to solve the authentication problem is just one of many
objects my applications store in the session.
The classic example people tend to use for session management is your shopping
cart at an e-commerce site. Somewhere, you want the server to keep track of the
items you have selected so far, but not get them mixed up with the items that
someone else might be choosing at the same time. User objects in your session are
a natural place to store the list of items you've chosen. (NOTE -- real life
shopping cart apps probably also copy the information to a database each time you
add a new item, so that your shopping cart is not lost if the server crashes and
needs to be restarted, but the basic concepts of per-user information storage is
what we are after in this discussion).
Longer answer #2: What concerns might we have about the information stored in a
user session? That requires a brief analysis of what can happen to it:
* Can some servlet or JSP page scribble on the
data in some other user's session? No, because there
is no mechanism in the API (2.1 or later) to get an
object reference to any session but the one that
corresponds to this request.
* Can the session disappear? There are two ways that
this happens -- either you called the invalidate() method
yourself (typically because the user logged off), or the
session timed out. There are mechanisms in the API
(HttpSessionBindingListener) to let the user objects
stored in your session to know that this happened, if
they need to do any cleanup themselves.
* Can they take too much memory? Again, the issues for
sessions are no different than any other Java objects in
your application. You have to decide how many simultaneous
users you expect to support, and what the average amount of
memory required for the user objects stored in their sessions
(you only have to count the data part -- the classes are loaded
once and shared across all instances. Multiply these two numbers
to determine the amount of real memory that should be available
for this purpose. If it's too big, you need to either reduce the
number of users you can support, change your application design
so that it does not require as much space per user, or buy
some more memory for the server.
>
> Thanks in advance,
>
> Juan Gargiulo
>
Craig McClanahan
===========================================================================
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
