aspose file tools*
The moose likes Servlets and the fly likes Best Practise and why Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Best Practise and why" Watch "Best Practise and why" New topic
Author

Best Practise and why

Steven Lau
Greenhorn

Joined: Mar 25, 2002
Posts: 9
When processing a request, what's the BEST suited implicit objects for sharing data between Servlets and JSPs? and why? is that application?
Anthony Villanueva
Ranch Hand

Joined: Mar 22, 2002
Posts: 1055
The session object, of course.
The pageContext object of course is totally out of the question.
The request object is only good for one request. Multiple requests will be treated as coming from totally different clients.
There is only one instance of an application object inside your web app. What happens when your web app starts servicing concurrent requests?
-anthony
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

Just to elaborate on Anthony's reply - the page context object is sent to and from the client. That means it's
1. extra network overhead
2. subject to being accidently lost
3. subject to being hacked.
You CAN lose a session ID, but it's harder (unless the client has disabled cookies and you support URL rewriting, but don't always do it right), Since the session ID is a "meaningless" information string, it's much harder to hack - the sensitive info never leaves the server.


Customer surveys are for companies who didn't pay proper attention to begin with.
Axel Janssen
Ranch Hand

Joined: Jan 08, 2001
Posts: 2164
If you want to share data for only o.n.e request, the request object is better.
Because its scope is narrower there will be less possible side-effects (one side-effect of session-objects is that they cost more ram)
Axel
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
...and another side effect of using the session to transfer data is that the data could be replicated when running in a cluster. Therefore, using the session to store "large" amounts of data could bring down the performance and scalability of your app.
Simon
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

No matter what method(s!) you use, it's ALWAYS good to minimize the size of your objects. Big objects can consume network bandwidth, local memory, and extra CPU.
However, I DON'T recommend using request scope merely for efficiency's sake. That's the kind of thinking that made Microsoft Windows what it is today - a bloated memory-eating CPU hog - oops, I mean a security nightmare.
Never put anything in request scope if you'll regret seeing it come back changed in ways you didn't want or expect - ESPECIALLY filenames, userIDs, passwords and other critical resource identifiers.
You can always buy bigger hardware, but when people come pounding on the door demanding to know why their credit-card numbers are public knowledge, having an "efficient" application will be small consolation.
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
If you're simply passing information between a servlet (say a front controller) and a JSP that service the same request then request scoped attributes (request.setAttribute(name, object)) are a good choice. You can then pick those objects up with request.getAttribute(name), pageContext.getAttribute(name, PageContext.REQUEST_SCOPE) or the equivalent useBean action.
However, if you want to pass data between different requests then, as Tim says, session is the way to go. Typically hidden fields are sometimes used to transfer additional pieces of information (they go on the roundtrip) but you shouldn't put confidential stuff in them.
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
Originally posted by Tim Holloway:
Just to elaborate on Anthony's reply - the page context object is sent to and from the client.

The pageContext just represents a JSP page's "view of the world" in the container - it doesn't get sent back to the client.
 
Don't get me started about those stupid light bulbs.
 
subject: Best Practise and why