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



    Hi Kelly,

    Just an opinion, of course, but I think you are much better off, both
for now and other projects, to resolve your issue with existing code rather
than trying to rewrite the code into different pieces on different machines
or use a language ( any language ) you aren't familiar with in a complex
effort.  And that doesn't even include portability considerations.

    If you have a dead horse, that's a different story, and I have no real
idea of what you are trying to do.  However, lots and lots of apps run well;
keep that in mind.  Opening and closing 4000 connections is going to be slow
no matter what.  In a later message you say:

> I originally did had it setup to open on start but kept running into a
> "maximum statement" error (I think that was the error).  And for the
> life of me I couldn't figure out why my statement.close() wasn't closing
> the statements for each individual methods.  In light of that I ended up
> putting an open/close connection in each method.

    If you have a problem like that, there are many places, including this
list, to get it resolved.  Since you only say "I think that was the error",
there's no point wasting time on it now.  I will say that something just
feels very wrong here, and you may need a larger review from other staff or
a trusted outside resource; mailing lists and forums aren't very good at
those situations.

    But, take a piecemeal approach first.  Also, do your stored procedures
make sense in context, like do you have to make 30 calls for small tasks
when one method could handle it?  What about batch updates?  There are lots
of possibilities.  Just IMO.


                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "Kelly Jones" <kjones@xxxxxxxxxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Thursday, April 27, 2006 3:52 PM
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
> Sr. Web Developer
> Chef's Catalog
> ph: (719) 272-2600
> fax:  (719) 272.2601
> email: kjones@xxxxxxxxxxxxxxxx
> web: www.chefscatalog.com <http://www.chefscatalog.com/>
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.