Database Connectors Explained | Lightboard Series

[@--Nath--]

Remember little bobby tables (from XKCD) for the second part of this (substituting parameters into SQL): you don't want to be manually sticking your SQL query together with values from the outside world. Always use substitution values to make things safer.

[@ashishg9089]

Hi Nathan, is there a way to externalize the DB connection pool in mule so that multiple system api's can leverage the connections from the common pool(just like datasources configured in traditional web/application servers like weblogic, websphere, tomcat etc)?

[@--Nath--]

Keep in mind that when you deploy an app (e.g. an API implementation) to CloudHub or RTF - it'll be just that one application on a mule runtime by itself. So there's no other applications on that runtime to share anything with. So for that sort of situation I would look more to what does your CI/CD server provide to manage the properties and "externalize" it that way.

[@--Nath--]

Now if you're going to a customer-hosted mule runtime where you'll have multiple apps on the same mule runtime - there's a concept called "domain projects" which can hold shared configuration. So if you truly need to share configuration between the apps (rather than having each with their own configuration/pool settings and credentials etc) then that could be an option.. But it does complicate things a bit and I'd generally try to keep each app isolated as possible (e.g. if one app goes haywire and uses up all the connection pool then you'll impact all the other apps). You also have to manually manage the deployment of that domain project - as it's assumed to be part of the mule runtime setup.

[@--Nath--]

So I would generally try to avoid replicating the (mess) that is having all connection pools/configurations as shared entities. Keep each app isolated, and ideally you should be having separate user/pass for each app too - as rolling passwords means a big bang if all the apps have used the same credentials.