Java and JDBC vs 4gl
Posted in 2003
Topics: Error Codes & Troubleshooting, Connectivity: ODBC / JDBC / .NET, Connectivity: ESQL/C, 4GL & Embedded SQL, Java & JDBC Development
Hi all, We plan to migrate our 4gl (7.31) batch programs from 4gl to Java (2.21.JC4). Our tests show us that the connexions on IDS server through JDBC are very slow compared to the connexions established by 4gl batches. Is it a know behaviour/bug ? For example, we have to perform the following requests in several parallel loops: - insert one row in tableA - update one row in tableB Both tables are in "lock mode row". Each loop accesses the same two tables, in a random way, so thah rows in tableB may be accessed concurrently. The connexions are established with "set lock mode to wait 1". With JDBC connexions, we observe very often error "-243 Could not position within a table, ISAM error -154" on the update statement. We never observe it with 4gl connexion. The error does no more appear with JDBC connexions with "set lock mode to wait 10." Any idea to accelerate the JDBC connexions ? Have we missed some settings ? Thank you, Philippe
Using standalone Java client will always be slower. What you can do is use application server like JBoss (or IBM WebSphere or BEA WebLogic or Jakarta Tomcat or ...) to establish database connection pool. This way, you'll always have connection ready to use. Then write standalone client that will use that pool... This will not resolve -243 errors though. I don't really know how to solve these. Are you using transactions in your code? Gorazd "Ph. Chantry" <sorry.nomail@mail.fr> wrote in message news:bpknug$drl$1@s1.read.news.oleane.net... > Hi all, > > We plan to migrate our 4gl (7.31) batch programs from 4gl to Java > (2.21.JC4). > > Our tests show us that the connexions on IDS server through JDBC are very > slow compared to the connexions established by 4gl batches. > Is it a know behaviour/bug ? > > For example, we have to perform the following requests in several parallel > loops: > - insert one row in tableA > - update one row in tableB > > Both tables are in "lock mode row". > Each loop accesses the same two tables, in a random way, so thah rows in > tableB may be accessed concurrently. > The connexions are established with "set lock mode to wait 1". > > With JDBC connexions, we observe very often error "-243 Could not position > within a table, ISAM error -154" on the update statement. We never observe > it with 4gl connexion. > The error does no more appear with JDBC connexions with "set lock mode to > wait 10." > > Any idea to accelerate the JDBC connexions ? > Have we missed some settings ? > > Thank you, > Philippe
> Using standalone Java client will always be slower. What you can do is use application server like JBoss (or IBM WebSphere or > BEA WebLogic or Jakarta Tomcat or ...) to establish database connection pool. This way, you'll always have connection ready to > use. Then write standalone client that will use that pool... Of course. In another context, we use a connexion pool (Caucho Resin). For the present tests, each loop is linked to one pre-established connexion. > Are you using transactions in your code? Yes. Each step in the loops is protected by a transaction. Using larger transactions (10000 steps for example) does not accelerate significantly the process. Thanks, Philippe
Sorry. Then I have no further ideas at the moment. Gorazd "Ph. Chantry" <sorry.nomail@mail.fr> wrote in message news:bpkro7$g13$1@s1.read.news.oleane.net... > > Using standalone Java client will always be slower. What you can do is use > application server like JBoss (or IBM WebSphere or > > BEA WebLogic or Jakarta Tomcat or ...) to establish database connection > pool. This way, you'll always have connection ready to > > use. Then write standalone client that will use that pool... > > Of course. In another context, we use a connexion pool (Caucho Resin). > For the present tests, each loop is linked to one pre-established connexion. > > > Are you using transactions in your code? > > Yes. Each step in the loops is protected by a transaction. Using larger > transactions (10000 steps for example) does not accelerate significantly the > process. > > Thanks, > Philippe > >