Peter Thomas wrote:
>
> Assaf,
>
> I'm interested in further details regarding your 2nd paragraph below.
> You say
> 'If you are retrieving the information purely for display and
> potentially
> updating one or two records, session beans will work faster. Way
> less
> overhead. You construct a query, get a result set, work with that
> result
> set. Entity beans add a separate layer'.
>
> Do you mean use stateful session beans that use raw JDBC to get all
> records ?
> Then return say first 100 to client ? Or do you mean still use
> Entity beans ?
I mean using JDBC directly from your Servlet/client application and
benefiting from all the capabilites of JDBC.
If you go through a session bean, you add the overhead of method
invocation, plus, the result set must be fully loaded into memory and
serialized to be returned to you. That makes sense if the client/server
are located across a network, it doesn't make sense if you are running a
Servlet which can go to the database and grab the information directly.
When you work with JDBC and say, retrieve 1000 records, the JDBC driver
can use fetch buffers to give you back 100 records at a time. Once
you're use a record, the JDBC driver can remove it from memory (forward
only cursors). Lean and mean.
IF you use a session bean, it must load all the records, serialize them
and return a serialized copy. So you get the overhead of serialization
(which is pretty significant) and you don't benefit from the value of
fetch buffers (which gives bettern response time).
arkin
>
> Pete.
>
> > -----Original Message-----
> > From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> > Sent: 26 February 2000 02:41
> > To: [EMAIL PROTECTED]
> > Subject: Re: Patterns for massive amounts of data?
> >
> > What you are looking for is a way to construct a finder that only
> > returns an interval group, say WHERE ID BETWEEN 1 AND 1000. That will
> > give you just the entity beans you are looking for.
> >
> > If you are retrieving the information purely for display and potentially
> > updating one or two records, session beans will work faster. Way less
> > overhead. You construct a query, get a result set, work with that result
> > set. Entity beans add a separate layer.
> >
> > If you are retrieving the information and potentially updating most of
> > the data, then having it in memory (entity beans) is easier to work
> > with.
> >
> > As for caching, I'm not sure it make sense. Let's say you have 1 million
> > records, you load 1000 and cache them, then load another 1000 (different
> > set) and cache them, then load another 1000. At this point the EJB
> > server will dump the first 1000 to make room for the new 1000, so you
> > end up getting nothing from caching.
> >
> > As a general rule if you load the same set of records 80% of the time,
> > caching is much faster. If you load a different set of records 80% of
> > the time, the 20% caching might be offset by the cost of using entity
> > beans, and session beans will run faster.
> >
> >
> > Another possibility, which totally bypasses EJB (but you need to
> > evaluate it based on how the client works) is to use JDBC directly from
> > the client for reading. In that case you can benefit from fetch buffers
> > (i.e. you read 100 at a time, out of the 1000 results) and offload a lot
> > of network activity (client->RDBMS as opposed to client->EJB->RDBMS).
> >
> > arkin
> >
> >
> > Jonas Wallenius wrote:
> > >
> > > Hi folks,
> > >
> > > A question about a probably quite common issue in n-tier apps...
> > >
> > > Suppose I have a java client - session bean - entity bean(s) - DB.
> > >
> > > Suppose the data we're dealing with consist of huge lists (of names, or
> > > whatever) PK:ed on a running integer. Could contain millions of entries.
> > > The data could conceptually be seen as consisting of interval groups,
> > where
> > > all entries in an interval belong together and are often retrieved and
> > processed
> > > together.
> > >
> > > The client user wants to perform a bunch of filtered searches on a list:
> > > "Show items 1-1000 and 1000-1500, show all names containing an 'a', ..."
> > >
> > > I'm wondering about two things here:
> > >
> > > 1) Is there some "common/best practice" for deciding how and when to
> > retrieve
> > > the data from the DB to the client? I'm particularly interested in
> > hearing
> > > of experiences comparing session bean -> DB via direkt SQL (stored
> > > procedures, etc) vs session bean -> entity beans (hopefully cached).
> > >
> > > 2) Is there some common/best practice of representing such massive
> > amounts of
> > > data in a client? What about in the database? Could the interval
> > group
> > > property of the data be exploited in some clever way?
> > >
> > > As for 1), the natural answer seems to me to be to fetch each data
> > interval as
> > > the user requests it. The downside to this might be that the server will
> > need to
> > > go through the entire data list each time a filter operation is
> > requested, which
> > > is why I'm asking for good ideas.
> > >
> > > As for 2), I don't mean graphically (though ideas for that are welcome
> > too :-)
> > > as much as structurally, especially in the case where the data can be
> > seen as a
> > > group of non-overlapping intervals (items 1-1000 and 2000-10000 and
> > ...).
> > >
> > > We can assume that the entity beans have exclusive write access to the
> > DB.
> > >
> > > Regards,
> > >
> > > Jonas
> > >
> > >
> > ==========================================================================
> > =
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
> >
> > ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
