Dan Hobbs <[EMAIL PROTECTED]> writes:

> Right. I had heard the term, but in a different context. I
> was just a bit confused about it!

Beans are very different to EJBeans. A bean is basically an object
that can be managed in a particular way (via introspection and
automagical guessing of methods and properties).


> Here are some example queries and their potential row count:
>
>    select all products available (10-150 rows)
>    select all clients who own a given product (anything up to 5000 rows
>     - though more likely to be a fraction of that)
>    select all clients (upto 5000 rows)
>
> Most pages take the form of a table consisting of each of the result
> rows, with each row being a link to a different page/servlet which
> would then "drill down" to more specific based on the
> selection. Could these be implemented like this? :
>
>           get preparedstatement cursor from pool
>           execute query
>           display results
>           return ps cursor to pool

That's right. Except you're not getting a cursor, you're just getting
a PreparedStatement object. In implementation terms the cursor is
probably not created until you call the PS's executeQuery() method.


> What about if I throw another spanner in the works in that the page
> may be refreshed, changing the ordering, if the user clicks on a column
> heading to select a different order-by field?

As long as you do the query again that's fine. This is why caching
the results can be beneficial. Note that JDBC 2.0 drivers do allow
you to do that, but you still have to cope with the cursor issue.

Of course, that's something you might want to construct the PS around,
the order by columns.

Last point on this: I once worked on an app that did sorting
extreemly well using client side JavaScript.


> Simplistically, the database contains a list of their clients (as I
> said before, upto 5000), what investment products they have
> available (I believe 100 is typical). A client's investment is made
> up of several investment products.

It's still not that big is it? Unless you're storing large amounts of
data about each client (and I mean large: nude pictures of all there
staff or something /8-).


> MDO allows the user (the portfolio manager) to select a client, and
> see their personal information, their investment preferences, which
> products they already have investment in, etc. The modelling aspect
> compares what they have invested with what they have stipulated as
> their preference, and gives hints as to which areas to invest
> in. The (as yet non-existent) orders section will then take on the
> orders and process them.
>
> Another view allows listing of the investment products, and then
> selecting one to see which clients have an investment of this type.

It depends on the required response time what you do. It seems that
the response time for this might need to be pretty high. In which
case you have to balance the quickness of the Oracle response against
the memory requirement of caching everything.

Caching everything is not generally what I'd do for an app of this
side so perhaps you do need to change it so that you've got something
a bit more conventional.

Generally, what I do, is have an object->table mapping. So in this
case there would be a Product object and a Client object. Those
objects have static methods which provide Iterator based abstractions
of the tables, for example:

  class Client:

     public static Iterator listByName (Connection con, String name)
        throws SQLException;

Produces an Iterator over the ResultSet of a query which selects the
clients that have a name matching the parameter.

This is quite a useful technique for cleaning up your code.

Often it is beneficial to use some sort of context representation
instead of a Connection. Such objects can encapsulate Connection or
PreparedStatement pools as well as other logic.


Nic

___________________________________________________________________________
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

Reply via email to