|
Kelly, I have seen similar problems in code that kicks off thousands of updates at once. Stored procedures help a lot if they batch up the updates. If you have a relatively new iSeries with some memory the next thing to do is run the Java on the iSeries. My experience is that this will improve performance significantly (5 to 10 times or so on our system). If you do this I would try out the native driver. Beyond that, you might want to pool some connections and run parallel processes. I you don't pool connections you will incur the overhead of between 4,000 jobs or initialization 4,000 times in one job. If you are getting too many statements, make sure you close the statements/connections in a try/catch/finally block. --David Morris From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kelly Jones Sent: Thursday, April 27, 2006 2:53 PM To: java400-l@xxxxxxxxxxxx Subject: Passing Java Object to iSeries So I was thinking... We have this Java app that runs on a WinTel box but gets it's data from the iSeries. Once all of the data has been mangled, massaged, twisted and bent to fit into the format we need, it is then piped back into a set of tables on the iSeries. One of the problems is that during the process of putting the data back on the iSeries, the application opens around 4000 JDBC connections. While this method works, it is somewhat slow. What I would like to do is pass the objects that have been created by the Java app back to the iSeries and let "something" deserialize them on the iSeries side and stuff the data into the tables. This would eliminate all of the JDBC connections that are currently part of the app. I could open one connection, loop over my stuff, have "something" on the other side deserialize each object and finally close the connection. I'm not familiar with what can be done on the "other side". Could RPG, CL, xxx be the "something"? Thanks, Kelly Kelly Jones
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.