Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Database pooling on iSeries

Learn why database pooling on iSeries causes jobs on server to remain active.

My company is developing a Web application (.NET) and uses Webservices to connect to iSeries.

Everything was OK, but recently we noticed that QZDASOINIT jobs are remaining active (with several locks) in the...

QUSRWRK subs, despite the connections being closed.

I've done some investigation and found out that the pooling property could have something to do with this.

Pooling = true gives us the current scenario; pooling = false gives us the desired scenario, as the QZDASOINIT jobs are terminated once the browser closes, but all the connections are extremely slow.

What we want is this scenario:
Each connection to iSeries creates an QZDASOINIT job and terminates it when is not needed anymore, but the connection is as fast as if we had pooling = true.

Is there any way to do this via .net code, connectionstring, or iSeries configuration?

Those QZDASOINIT jobs are database server jobs that sit in a wait state waiting for a request from a remote client looking to run database work. You are correct that those jobs stay active if you use pooled connections. You should check the actual CPU seconds consumed. While the jobs are active, they don't consume any significant CPU and probably get swapped from memory (if that's a constraint) if there is no activity for an extended period of time. In short, in a pooled environment, they are generally not a bad thing at all. Pooled connections avoid the overhead of starting and stopping database jobs on the system, instead sharing existing jobs wherever possible. This is normally a good thing from a performance perspective.

Good luck with it.

Dig Deeper on DB2 UDB (universal databases)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.