What is the best practice for housing MQ connection pools? Is it good to house them under single MQ connection pool package enterprise wide for all projects? Or is it good practice to house the connections in different packages along with other services making them project specific?

Its good practice to maintain JDBC/MQ connections in a package(like repository) which this be accessed by enterprise wide,this helps when maintainence/issues/migration etc…

HTH,
RMG

Last time we had an issue with MQ listener. The Disabled switch was not displayed. Only when the package was re-loaded, the handle to the Queue was released and the switch became visible again. This package was project specific and housed both the code and connection pools. So downtime effect was just local.
If we implemented an enterprise wide connection pool package and if we have issues with individual connection pools, I was wondering if it would affect all the projects in your enterprise, if we had to re-load the package? I would definitely appreciate, if you would share your experience in this context so far in your implementations.

I think you’ve more or less outlined the viable options. Personally, I’d group all connections for a given integration (there are likely no more than a couple) into a package by themselves and would not place all connections into a single package. I’d place the services that use those connections in other package(s). The rationale: connections don’t usually change much, services do; connections are usually environment specific (dev, test, prod) so migrating a package with services will likely mess up your connection configs.

This applies to any sort of connections, including DB connections. Isolate connections from the services that use them. Group connections by logical grouping.

Thanks much. That sounds like it will resolve all issues. Only remaining question i have in this context is, would this result in too many packages which consume additional memory at runtime? Is the cost significant?

srinivas wrote:
“…this result in too many packages which consume additional memory at runtime? Is the cost significant?”

Yes, additional memory will be consumed for loading the package. No, the additional usage will not be significant since it will be minor package management overhead.