> -----Original Message-----
> From: Nic Ferrier [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, April 03, 2002 3:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Question re servlet database application
>
Thanks for your response, Nic. I'll see what I can add...
> Beans is a Java specific term, ie: it means something specific to
> Java developers. It sounds to me like these objects _are_ beans.
>
Right. I had heard the term, but in a different context. I was just
a bit confused about it!
> Pretty low requirements, the situation you've been left with will be
> okay as long as there aren't too many rows.
>
> If I understand you correctly you've got a row->bean mapping, that's
> not necessarily a good thing but then neither is changing all the
> code.
>
> If you've got many rows and you're creating some in memory cache of
> what is in the SQL tables then that's probably not that good. But if
> the beans are all small self contained objects then an initialization
> synch with the SQL tables isn't that bad.
>
With the test database I'm connecting to, it takes around 90 seconds
to load the data. I believe some of our customers' databases are up to 2500%
the size of the test database, which rules out the initial load
unfortunately.
> > 1. The login mass data load is removed, and instead all the data
> > retrieval, instead of being from memory, is rewritten to use
> > prepared statements and get the data which would be better cached by
> > Oracle anyway than being read into memory. Any future update
> > statements (and selects which read from the relevant tables) would
> > have to be synchronized.
>
> This would be ok... you have XX problems though:
>
> i) a PreparedStatement owns a cursor and therefore a Connection. You
> could try and write a PS pool to allow you to share a small number of
> PS's across all your requests. That's often a useful trick but there
> is one catch to it, you're ResultSet must be closed at the end of the
> request (so you can check the free PS back into the pool). Some
> requirements don't easily facilitate that.
>
> ii) you're now doing many queries that possibly return the same data
> over and over. Depending on what you're doing this can be useless
> load, eg: you're returning the same query results to multiple
> people. There are ways round that (server side caching of resulting
> pages) but they're perhaps more tricky than just reading everything
> into memory and spitting it out a lot.
>
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
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?
> This is not a good idea. EJB is an advanced architecture that is not
> suited to the kind of small application that (it sound like) you're
> dealing with.
>
> Interestingly, if you went down the EJB road, you'd end up with
> something that is not dissimilar to your current system; the EJB
> container would cache instances of the entity beans (which would
> presumably represent a table row) until you had something approaching
> the memory use you have now.
>
I thought as much, from the little overview I've read, but thanks
for clarifying.
> Personally, I'd stick with what you've got, unless you're having a
> problem or it won't scale to what you want to do.
>
I think, given that the first customers who will buy this new
product are our largest existing customers, the scalability is indeed an
issue.
> You were a *bit* vague and thus my response is a bit vague too... if
> you tell us _specifically_ what you're doing then we can help a bit
> more specifically /8->
>
I was desperately trying not to write too much detail so I wouldn't
just be ignored! :-)
My apologies. To provide a little background info...
I work for IMVS plc, and we have products which help Investment
Portfolio managers (mostly small firms) manage their clients' investments.
The product I am working on (MDO - models, decisions and orders)
accesses an Oracle database which is populated by an existing product called
APA (Advanced Portfolio Management) which does all sorts with managing
clients, investment products, and lots of other stuff I don't yet fully
understand. :-)
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.
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.
As for the deployment platform, it is intended that we run these
servlets in Tomcat, itself running under either Apache or IIS - I believe
Apache is favoured.
I hope this helps aid your understanding of the situation. Thanks
for your time in reading this effort!
Regards,
Dan
___________________________________________________________________________
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
