S
slacroixak
Guest
Thank you for your input Rob. However this reminds me hard some Sonic days** Just splitting the connection needs with two brokers for ABL Apps and SQL reporting is not enough. We also have some Java Apps doing SQL too. An efficient DB system would let us handle a maximum number of connections for some defined *users* (with patterns for unlimited or 1..). Example: ServiceA 4 connections, ServiceB 3 connections... and so forth. I do not know if such a DB system exists yet... This way, a faulty service would not mess up the entire system by consuming all the remote servers. This would also add value to using well defined and dedicated users.. For now, too many systems just use one single Technical DB User that makes it very hard to diagnose connection leaks problems. So for now, we have to handle this rule on the client side (in our case, the faulty application is a Java that was creating to many connections for a short while), with a limited pool of connection. But still a well dedicated App can be victim of a non well educated App. In that picture, having something simple that auto trim non used remote servers would be helpful even for production. At the end of the day, the one that survives is not the purest, but the one that leaves/makes less problems... ** for large messaging infrastructures, where we had to define many acceptors to anticipate this kind of situation. Our messaging system was looking like a labyrinthine system to handle non-explicit complex rules, very hard to maintain.
Continue reading...
Continue reading...