× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Nathan,

With native access you will not have the socket overhead. I am not
sure how it works under the covers, but it is noticeable faster on our

system. Oracle also has this native connection ability, but the 400's
is easier to use and does not impose the same restrictions and risks.
When we tried this with Oracle, performance would oscillate between
very good and very bad no matter how we allocated memory and
configured the JVM and Oracle.

As for reliability, we have both AS/400s and Windows servers running
Servlets. On a Windows 2000 server that only runs Java, it is pretty
reliable. That means you must use sockets and have at least two
servers one for your database and one for Java. We run a 24/7 x 364
plant on a Windows 2000 (not my choice) Tomcat server. It is a
Top of the line server that is mirrored, completely redundant. In one
year it has failed twice due to a bad ethernet card and a communication

error that it could not recover from. That could happen on an AS/400,
but
my experience has been much better. In the end, this set of servers
cost
more than two AS/400's because it ended up being 5 servers, along with

enterprise level Windows and Oracle software.

I think quite a few projects start out with a decision that a single
Windows
2000 server is cheaper than an AS/400. If you don't need a test
environment, development environment, or database, and you are OK
with building/rebuilding boxes for each developer/test environment,
it makes sense.

With windows you cannot set priorities, so you may need two
servers -- one for batch and one for interactive processing. That
implies
you will redirect requests to the batch server, which means you also
have to duplicate the request and pass it along. For example, if you
want to generate a PDF file to print and you know it will take 30
seconds, everyone on the Windows server suffers. On the AS/400,
you can change the priority of that thread to a batch priority.

David Morris

>>> nandelin@relational-data.com 05/14/02 05:34PM >>>
> From: "David Morris" <David.Morris@plumcreek.com>
> Your assumption that all connections are via TCP/IP is
> incorrect.  If you use the native drivers, you will bypass
> the overhead associated with TCP/IP.

My understanding of the use of sockets to interface with native
resources
was based on reading.  Not completely assumption ;-)

If os/400 Java and native components are not communicating via sockets,
then
what?  Memory pointers?

By "native drivers" are you referring to the record level access
support
provided in the iSeries Toolkit?

> Some things I would say are an advantage on the iSeries
> other than reliability...

I'd like to understand the reliability issue better.  It seems that an
integrated xSeries server would be quite reliable (from a hardware
perspective).

But I wonder about the reliability of the JVM under Windows or Linux.
One
way to destabilize Windows is to concurrently run a lot of different
software
(executables, DLLs, and activeX controls).  But that's not the same as
concurrently running a lot of classes within a single JVM.  In one case
the
OS is managing (trying to, anyway) the workload.  In the other case the
JVM
is managing the workload.  Is the OS/400 JVM more stable than one
running
under Windows or Linux?

> ability to set priorities for jobs and threads
> the ability to associate individual users with a task.

Is that important if you're just running Servlets, JSPs, and Beans
under
Tomcat?

Thanks for your reply,

Nathan M. Andelin
www.relational-data.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.