Názor k článku PostgreSQL 17: pádící slon nezpomalí od Ivan Brezina - Oracle to ma stejne. Pocet spojeni je parametr,...

Oracle to ma stejne. Pocet spojeni je parametr, ktery urcuje velikost datovych struktur uvnitr databaze, a tenhle parameter se neda za jizdy zmenit. (Shared server vynechavam). "Normalni" SpringBoot aplikaci(OTLP) by mel stacit connection pool, ktery ma nizsi destitky spojeni. A na strane dabaze muze byt limit na pocet spojeni do tisice.
Navic na limit na pocet DB spojieni jsou navazany i kernel parametry na pocet otevrenych souboru, pocet zamku, ..., ktere DBA vetsinou neresi, protoze na to nemaji prava.

Problem je se starymi Java aplikacemi, ktere reaguji na kazdou neocekavanou vyjimku tak, ze se thread ukonci a konexe uz se nikdy do poolu nevrati. To pak vede situaci ze jsou vsechny limity na spojeni neumerne velke. To ale neni reseni ale jen w/o. Oracle na to "vymyslel" feature v connection poolu UCP, ktery umoznuje zabijet i konexe, ktere ma aplikace vypujcene, ale uz nekolik hodin je nepouzila.

Jedina DB o ktere vim ze to nejak resi je Infoxmix - ten je ale mrtvej. Ten bezi multivlaknove a navic ma vlastni scheduler vlaken, takze muze jedno vlakno behem vykovanani SQL dotazu "preskocit" a pokracovat ve vykonavani jineho dotazu.