RE: Database Maintenance Models

> From: Nathan Andelin
> 
> More precisely, Servlet containers are multi-threaded, placing the
burden
> on
> Servlet and framework developers to synchronize their methods.  If one
(1)
> Servlet is responsible for database inquiry and maintenance for so
many
> files, supporting so many users, wouldn't that be a serious bottleneck
for
> high-volume sites?

That really depends on your design.  One technique I use is a servlet
proxy that is not multithreaded that established a connection with a
batch job.  There are dozens of other ways to do this, with various
tradeoffs. 


> > So if you have modeled this using any of the standard
> > modeling tools, I think the resulting UML would be a
> > great addition to the discussion.
> 
> UML discussions tend to become too theoretical.  In contrast, if one
shows
> a
> picture of a typical database maintenance activity, folks can more
easily
> comment on useful or possibly missing features.

But that's not the focus of this list.  This is a discussion of using
Java on and around the iSeries, not one of general application
architecture.  This list is focused on determining where Java is
appropriate, and how to make Java interact with non-Java components.
We're not here to gather functional requirements for applications.
That's in fact WHY I created the new web site, which you might want to
avail yourself of.  Or you can petition David for an application design
list, where all these things can be discussed.  But discussions of the
specific UI practices of an RPG modeling technique are inappropriate for
the JAVA400-L list.


> Models apply to situations where large-scale applications are being
> rewritten, involving hundreds of database maintenance programs.  Is
this
> topic outside the scope of the Java community?

It's outside the scope of this list.

Joe