without understanding the details of your task at hand the ServletContext
provides a place to access data which is scoped at the web application
(see http://java.sun.com/products/servlet/2.2 -> web application) level
vs the session or request. in practice and imho i believe the session bucket
will be used most often as this is where you "personalize" the content. the
request bucket helps to get from "page a to page b" and as such is helpful
for some situations. the servlet context bucket is a good "global resource"
space which spans sessions (aka users) and requests (aka http get|post).
as to the persistency issue, you should consider the framework necessary
to bootstrap the data upon application/server startup, the runtime interaction
(ie getters and setters) and lastly the final storage as the system shuts down.
you might want to consider serializing the objects, stuffing it in a database
or something of the like.
hope this helps,
- james
Rajendra Mishra wrote:
> ----- Original Message -----
> From: James Todd <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, November 14, 1999 2:52 AM
> Subject: Re: TWO PROBLEMS !!
>
> > regarding variable passing, craig has done a smash up job of answering
> > this and other questions in the past. some relevant comments on this
> > topic can be found in the list archives at:
> >
> >
> http://archives.java.sun.com/cgi-bin/wa?S2=servlet-interest&q=setAttribute&s
> =&f=cmcclanahan%40mytownnet.com&a=&b=
> >
> > i couldn't find the exact message i was looking for but in the
> > archives is a message where craig clearly states when one should
> > consider using Request, Session or ServletContext scoped storage
> > schemes along with a the relevant 2 to 3 lines of code. the man
> > should write a book ... anyways ... the basic theme is:
> >
> > data with which you wish to share across the life of a single
> > http request and no more should be handled by the
> > ServletRequest object via the get/set Attribute methods.
> >
> > data with which you wish to share across multiple requests
> > for the same user during the lifetime of a single session should
> > handled by the HttpSession object via the get/set Attribute
> > methods.
> >
>
> > data with which you wish to share across users, sessions and
> > requests should be handled by the ServletContext object via
> > the get/set Attribute methods.
> >
>
> By this, do you mean that the data is persistent across sessions for a
> client? For exp, I have a user who selects a site nbr. Depending upon this
> selection, I return the appropriate database connection to all the servlets
> which requests it. Since it is not cecessary for the user toselect the site
> agian, I need to store this site as a client/machine/user (?) specific
> attribute. Ths user is not required to select the site again(he can change
> it though.).
> Given this scenario, would a ServletContext work or I would have to write an
> extrnal file/hashtable where a list of users with their current preferences
> would be stored?
>
> Thanks.
> raaj.
>
> > note: some of the above is servlet 2.2 specific and may not
> > directly address servlet 2.1 or lesser implemenations. in
> > this area the servlet 2.2 spec made the data accessors more
> > consistent accross the api.
> >
> > you can store data in other more exotic containers (eg database,
> > singleton, ejb) but i have a feeling even if you do this some
> > subset of the associated data will be stored in one or more
> > of the above mentioned javax.servlet.* constructs.
> >
> > hope this helps,
> >
> > - james
> >
> >
> >
> > Ted Neward wrote:
> >
> > > I can certainly answer the second one, but I'll defer the first one to
> > > others more comfortable with the Servlet spec than I.
> > >
> > > Using stored procs does for you what using methods to access private
> data
> > > does within Java classes: it helps encapsulate the details of the
> > > underlying database schema. By using stored procs to obtain and/or
> > > manipulate the entities within the database, your DBAs can shuffle the
> > > schema around as necessary (to optimize for size, speed, certain
> queries,
> > > whatever is necessary) without having to recompile SQL code. (Other
> > > approaches to achieve this same effect include placing the SQL within
> text
> > > files that the application simply reads and executes, but then if the
> SQL
> > > changes, all of those "SQL properties" files require updating--not a
> > > simple chore.)
> > >
> > > Since you're using Oracle, you may as well make use of Oracle's rather
> > > powerful PL/SQL language and syntax. Note that you're still using
> > > JDBC--you're just using it to make stored proc calls, instead of
> directly
> > > executing SQL statements.
> > >
> > > Ted Neward
> > > http://www.javageeks.com/~tneward
> > >
> > > On Thu, 11 Nov 1999, Lalith Jayaweera wrote:
> > >
> > > > Hi
> > > > I need Ur help to sort it out following twoe two questions .
> > > >
> > > > (1) How can we pass a variable which is used in one servlet to another
> > > > servlet which will be used later.What am currently doing is creating a
> > > > session object and putting the value and getting the value back when
> > > > necessary.Is there any otherway that I can use instead of this one.
> > > >
> > > > (2)Rather than using jdbc.. for database access(writing sqlcodes well
> > > > within the servlet) is there any advantage if I can use stored
> > > > procedures.(am using
> > > > oracle as my database server);
> > > >
> > > >
> > > > Thanks in Advance
> > > > lalith
> > > >
> > > >
> ___________________________________________________________________________
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > > > of the message "signoff SERVLET-INTEREST".
> > > >
> > > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > > Resources:
> http://java.sun.com/products/servlet/external-resources.html
> > > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> > > >
> > >
> > >
> ___________________________________________________________________________
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > > of the message "signoff SERVLET-INTEREST".
> > >
> > > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > > Resources: http://java.sun.com/products/servlet/external-resources.html
> > > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
> ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
