Re: JDBC and Stored procedure performance problems
- From: "Saml" <none@xxxxxxxxxxxxxxx>
- Date: Sat, 7 Jan 2006 12:48:19 -0500
Coming in late on this thread...
There is an overhead on the iSeries in getting the JVM started, so maybe
this is what you are seeing. You may need to pre-start a bunch of JVM, so
that one is nearly always available. Can't provide the technical details,
but your system admin folk should be familar with pre-start jobs.
Sam
"Mark" <Smits@xxxxxxxxxxxx> wrote in message
news:1136566084.753375.150410@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> We are using a connection pooling mechanism but only to reuse the
> connections, not opening them in advance. Right now I am creating a new
> connection if all are in use and opening it in advance. This takes
> about seven seconds off from the waiting time, so it's a step forward.
>
> Activation group is *CALLER, so that is in order too.
>
> The same SQL statement takes just a second in STRSQL, so it's hard to
> believe it takes up so much time in a stored procedure, althoug being
> embed SQL RPGLE. I have timed the JSP and classes but the bottleneck
> seems to be in the single "execute" statement to activate the stored
> procedure and getting back the resultset.
>
> I haven't got around in putting some timing code in the stored
> procedure itself, but will do so next. The delay must be somewhere...
>
> Thanks for the pointers. Opening the connection in advance already
> helped.
>
.
- References:
- JDBC and Stored procedure performance problems
- From: Mark
- Re: JDBC and Stored procedure performance problems
- From: matt . haas
- Re: JDBC and Stored procedure performance problems
- From: Mark
- JDBC and Stored procedure performance problems
- Prev by Date: Re: Why Do I Get: SSL_ERROR_NOT_TRUSTED_ROOT
- Next by Date: Re: Ops Console to Physical Console
- Previous by thread: Re: JDBC and Stored procedure performance problems
- Next by thread: Screen attached printers
- Index(es):
Relevant Pages
|