|
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 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.