Well, my application distinguishes user sessions so that a user can login
multiple times in separate browser windows. A user session is stored in the
browser session and can be used to differentiate same user/different task
situations. But there are ways to send information that identifies one user
query from another without requiring a login, such as sending a query time
timestamp id. Not sure if you are asking if "it is possible" or "is it
possible". If the first, and a requirement then you would have to build
such a differentiator into your web app. If the second, then yes it is
possible. It just requires more work.
Dan
> ----------
> From: Ian[SMTP:[EMAIL PROTECTED]]
> Reply To: Ian
> Sent: Tuesday, November 16, 1999 9:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: How should support for scrolling large lists be
> designed?
>
> Daniel:
>
> Thanks for the reply.
>
> I am curious as to how you handle the possibility that the user has more
> than 1 'active' query as a byproduct of surfing your site. I.e., it is
> possible for them to back/forward/history to a results page from an
> earlier
> query.
>
> Thanks,
>
> Ian
>
>
> ----- Original Message -----
> From: Kirkdorffer, Daniel <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, November 15, 1999 11:12 AM
> Subject: Re: How should support for scrolling large lists be designed?
>
>
> > An approach I use is the following:
> >
> > - Limit how many rows you return on any query. If the query returns
> more
> > rows than your limit, then suggest a more limiting query constraint. I
> > limit to 1000 rows.
> > - Limit the number of rows you display per page. Realistically,
> displaying
> > too many rows in an HTML page, especially if you use HTML TABLEs to
> format
> > the output, will severely impact performance and memory on the client's
> > desktop. Too many rows and the data takes overly long to render. Some
> > people don't have enough memory to display very large pages. So I limit
> to
> > 50 rows per page, sometimes making the page size setting a user
> preference.
> > Of course it all depends on how much data/HTML you return per row.
> > - I store the keys from my resultset with the session object, and from
> > next/prev request to next/prev request, I access the appropriate keys
> > instead of re-running the query (via a SELECT ... IN ... query). This
> > reduces the storage per user, and it produces faster paging. It also
> means
> > that the user prev/next pages through the resultset of the original
> query,
> > and will not pick up new rows that meet that original query until a
> brand
> > new original query is performed. This is a tradeoff we can live with.
> > - I've established a cursor object that keeps track of my position so I
> can
> > correctly access the appropriate stored keys as I prev/next/first/last
> move
> > through my result data.
> >
> > So an example of the above might be a query that returns 800 rows. Here
> is
> > basically what I do (note: I do this stuff in a servlet, because that's
> the
> > way I architect my JSP systems - JSP>Servlet>JSP):
> > - store the keys for all 800 rows in a Vector I store with the session,
> > - store the first 50 rows of data from the same query resultset in an
> object
> > I pass to my web page for immediate display,
> > - hook my cursor object to the key Vector,
> > - display the page.
> >
> > If the use selects to move to the next page of the results I:
> > - use my cursor object to determine the next 50 keys from my key Vector
> and
> > create a SELECT FROM ... WHERE ... IN (key51, key52, ..., key100) and
> > execute the query,
> > - update my cursor
> > - store the rows of data from the key query in an object I pass to my
> web
> > page for immediate display,
> > - display the page.
> >
> > And so on. I can bounce around my results as I wish this way, forward,
> > backward, first, last, jump to a specific starting row, etc...
> >
> > I probably spent about a month of my time developing the classes I use
> to
> do
> > all this before I began developing my first JSP project, and I've used
> them
> > ever since (for the past 14-15 months). My data objects are generic and
> > store all the resultset meta data I need (type, length, nullable, name),
> so
> > I don't have to create new data beans for every data view I have.
> >
> > HTH,
> >
> > Dan
> > --
> > Daniel Kirkdorffer
> > NACN IS: 425-580-6225
> > Sr. Consultant, Syllogistics LLC
> > Email: [EMAIL PROTECTED]
> > Web: http://www.syllogistics.com/
> >
> > > ----------
> > > From: Ian[SMTP:[EMAIL PROTECTED]]
> > > Reply To: Ian
> > > Sent: Monday, November 15, 1999 10:13 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: How should support for scrolling large lists be
> designed?
> > >
> > > Hi Craig and all:
> > >
> > > This must be an area of concern for many people!
> > >
> > > If a site has potentially thousands of simultaneous users, each doing
> a
> > > general search that potentially has a resultset of thousands of rows -
> how
> > > should the paging/scrolling of the resultset be designed? What level
> of
> > > detail are people saving in the resultset if they use this approach?
> > >
> > > How do the major search engines support page prev/next? Are they
> really
> > > storing a session-specific resultset? Even when there are thousands of
> > > potential rows?
> > >
> > > I have seen a reference to one solution that advocates storing a
> > > second-level key to the resultset and defining a second cursor that
> can
> > > reposition at a specific page by using this key - but this seems like
> a
> > > LOT
> > > of extra work to me, and it doesn't support paging backwards very
> well.
> > >
> > >
> > > Thanks for any ideas/experiences,
> > >
> > > Ian
> > >
> > >
> > > ----- Original Message -----
> > > From: Craig R. McClanahan <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Monday, November 15, 1999 9:49 AM
> > > Subject: Re: JDBC from JSP
> > >
> > >
> > > > "Loganathan, Kamalesh" wrote:
> > > >
> > > > > My application is a reporting & monitoring application.
> Personally,
> I
> > > don't
> > > > > want to use any database related classes in jsp page. Instead, I
> would
> > > like
> > > > > to create report (wrapper ?) beans and use them in the page. But,
> > > should I
> > > > > create a bean for each row (entity) or use a manager bean as
> wrapper
> > > class
> > > > > for resultset ??
> > > > >
> > > > > Any comments ??
> > > > >
> > > >
> > > > If you are using the ResultSet, either directly or indirectly via a
> > > wrapper bean,
> > > > there are some implications:
> > > >
> > > > * The ResultSet must remain open (potentially across multiple
> > > > requests if you allow the user to scroll forwards and backwards
> > > > by pages like a search engine does).
> > > >
> > > > * Therefore, the Statement from which this ResultSet was created
> > > > must remain open.
> > > >
> > > > * Therefore, the Connection from which this Statement was created
> > > > should remain exclusively allocated to this user (to avoid
> problems
> > > > with transactional commits and rollbacks affecting the results).
> > > >
> > > > On the other hand, if you create business object beans to represent
> your
> > > results,
> > > > you can close the ResultSet and Statement, and return the connection
> to
> > > your
> > > > connection pool, as soon as the query completes. This can
> substantially
> > > increase
> > > > the number of users your application can support with a given number
> of
> > > > connections.
> > > >
> > > > 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
> > > >
> > >
> > >
> ==========================================================================
> > > =
> > > 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
