•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the JSP section within the Web Development category of DaniWeb, a massive community of 397,813 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,553 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our JSP advertiser: Lunarpages JSP Web Hosting
Views: 2126 | Replies: 4 | Solved
![]() |
•
•
Join Date: Apr 2007
Posts: 5
Reputation:
Rep Power: 0
Solved Threads: 0
Hi all,
I'm currently building a login page for a JSP application, I've realised that im going to need to use sessions to recall the username on the login screen for other functionality.
Unfortunately i'm very new to the whole web development approach and i've tried searching for guides on JSP sessions but haven't manged to find anything.
Could anyone point me in the direction of a decent tutorial or help me out with some code for parsing a value e.g. "username" to a session and recalling for a later function.
Thanks for your time,
Rob.
I'm currently building a login page for a JSP application, I've realised that im going to need to use sessions to recall the username on the login screen for other functionality.
Unfortunately i'm very new to the whole web development approach and i've tried searching for guides on JSP sessions but haven't manged to find anything.
Could anyone point me in the direction of a decent tutorial or help me out with some code for parsing a value e.g. "username" to a session and recalling for a later function.
Thanks for your time,
Rob.
•
•
Join Date: Dec 2004
Location: London or Slovakia
Posts: 2,183
Reputation:
Rep Power: 10
Solved Threads: 265
Servlets and Java Server Pages http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
and on same site tutorial on sessions http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
but I will recommend to read basic about servlets and do JSP
and on same site tutorial on sessions http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
but I will recommend to read basic about servlets and do JSP
Learn to see in another's calamity the ills which you should avoid.
Publilius Syrus
(~100 BC)
If we helped you to solve your problem, answered your question please mark your post as SOLVED.
Publilius Syrus
(~100 BC)
If we helped you to solve your problem, answered your question please mark your post as SOLVED.
•
•
Join Date: Mar 2007
Posts: 83
Reputation:
Rep Power: 0
Solved Threads: 2
The links provided to Marty Hall's book info have some valid information, but they book is not good, Marty Hall intentionally avoids anything useful in all but the most trivial applications. Also the book is QUITE old... That said, the sections on sessions shoudl be useful...
You may want to just limit your form's memory to cookies... which you can handle with Javascript...
I don't like to use sessions to store ANY information until I know the user is valid... Cookies will remember across session too, and server restarts, etc. so they are better for login page memory...
For form memory for internal forms, once the user has logged in, you have DB, XML, etc. that you can leverage... obviously DB is the best choice if you are using one... only resort to text files such as XML if you can't use a DB...
Also, once the user logs in you can store their user name etc. in sessions, but be careful... too many developers get carried away with session information... its like taking them to the candy store when they're 8 and letting them run loose... they want to save everything...
The problem is knowing when the data is safe to remove from the session to prevent a memory leak type situation... I know it isn't a true memory leak, as the session will "hopefully" be invalidated and the memory recovered... BUT imagine a system that tracks 20KB of information about each user in the session, 20KB isn't much these days... NOW a system that only tracks 5KB... how many more concurrent users will the second system be able to support before resources become an issue....
This is a serious problem for many developers... many of the best make serious errors here and the resultant systems can cost the customer 100's of thousands in additional hardware costs to cluster support for more users... and 100's of K$ more in development costs to built the clustering support into the application....
Keep It Simple XXXXXX I don't like to use the other S word in that... Smart people don't always act very smart, but that doesn't make them less intelligent... perhaps less wise....but not less intelligent...
Anyway, I don't know what "other" reasons you have, but typically you DON'T CARE who the user is until they login... and thus cookies are better for non-logged in users... put the memory restriction on the guest until they validate themselves...
If you DO resort to using sessions for non-logged in users, be careful to use them wisely, and clear unused data as soon as it is no longer valid...
Also, session stored data is difficult to update "on the fly" ... what I mean is that if you store user preferences, etc. in the session when they login, then they go to the preferences page and change them, you have to manually update them for that user... BUT what if a user's preferences effect someone else's viewing experience... if the preferences change, you have no easy way to notify the other user's sessions that they need to be updated too...
Actual case I ran into recently when reviewing code written by oneof my developers...
OK, good luck...
You may want to just limit your form's memory to cookies... which you can handle with Javascript...
I don't like to use sessions to store ANY information until I know the user is valid... Cookies will remember across session too, and server restarts, etc. so they are better for login page memory...
For form memory for internal forms, once the user has logged in, you have DB, XML, etc. that you can leverage... obviously DB is the best choice if you are using one... only resort to text files such as XML if you can't use a DB...
Also, once the user logs in you can store their user name etc. in sessions, but be careful... too many developers get carried away with session information... its like taking them to the candy store when they're 8 and letting them run loose... they want to save everything...
The problem is knowing when the data is safe to remove from the session to prevent a memory leak type situation... I know it isn't a true memory leak, as the session will "hopefully" be invalidated and the memory recovered... BUT imagine a system that tracks 20KB of information about each user in the session, 20KB isn't much these days... NOW a system that only tracks 5KB... how many more concurrent users will the second system be able to support before resources become an issue....
This is a serious problem for many developers... many of the best make serious errors here and the resultant systems can cost the customer 100's of thousands in additional hardware costs to cluster support for more users... and 100's of K$ more in development costs to built the clustering support into the application....
Keep It Simple XXXXXX I don't like to use the other S word in that... Smart people don't always act very smart, but that doesn't make them less intelligent... perhaps less wise....but not less intelligent...
Anyway, I don't know what "other" reasons you have, but typically you DON'T CARE who the user is until they login... and thus cookies are better for non-logged in users... put the memory restriction on the guest until they validate themselves...
If you DO resort to using sessions for non-logged in users, be careful to use them wisely, and clear unused data as soon as it is no longer valid...
Also, session stored data is difficult to update "on the fly" ... what I mean is that if you store user preferences, etc. in the session when they login, then they go to the preferences page and change them, you have to manually update them for that user... BUT what if a user's preferences effect someone else's viewing experience... if the preferences change, you have no easy way to notify the other user's sessions that they need to be updated too...
Actual case I ran into recently when reviewing code written by oneof my developers...
OK, good luck...
•
•
Join Date: Nov 2004
Location: Netherlands
Posts: 5,661
Reputation:
Rep Power: 18
Solved Threads: 193
if you can't find anything about session management and JSP you haven't looked...
you don't. Leave it to the server to decide what session storage system to use. It will use cookies if needed and possible, other systems as required.
There's rarely a requirement to set a cookie explicitly, just about the only time is if you want to persist something across sessions clientside.
which is pointless to do explicitly as it's automatically done for you. The session expires after a period of time and whenever the user closes his browser window he no longer has access to it.
Hardly. I've worked with JSP and servlets for a decade and that's never been a problem even on high volume online banking sites I've worked on.
Of course any halfway decent developer knows what's to be stored in a session and what's not.
He'll not store things there that aren't needed across requests for example, unless maybe if retrieving that data is very expensive.
•
•
•
•
You may want to just limit your form's memory to cookies... which you can handle with Javascript...
you don't. Leave it to the server to decide what session storage system to use. It will use cookies if needed and possible, other systems as required.
There's rarely a requirement to set a cookie explicitly, just about the only time is if you want to persist something across sessions clientside.
•
•
•
•
If you DO resort to using sessions for non-logged in users, be careful to use them wisely, and clear unused data as soon as it is no longer valid...
which is pointless to do explicitly as it's automatically done for you. The session expires after a period of time and whenever the user closes his browser window he no longer has access to it.
•
•
•
•
This is a serious problem for many developers...
Hardly. I've worked with JSP and servlets for a decade and that's never been a problem even on high volume online banking sites I've worked on.
Of course any halfway decent developer knows what's to be stored in a session and what's not.
He'll not store things there that aren't needed across requests for example, unless maybe if retrieving that data is very expensive.
42 Private messages asking for help will be ignored
In the frozen land of Nador they were forced to eat Steve's iMinstrels, and there was much rejoicing.
In the frozen land of Nador they were forced to eat Steve's iMinstrels, and there was much rejoicing.
![]() |
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
•
•
•
•
DaniWeb JSP Marketplace
Similar Threads
Other Threads in the JSP Forum
- Previous Thread: how to read data from database page by page, please it is urgent...
- Next Thread: how to insert a array of data into database in jsp



Linear Mode