Ano, obecně musíte pro každé vlákno vytvořit nové připojení. Nemáte kontrolu nad tím, jak operační systém zkracuje provádění vláken (nehledě na definování vlastních kritických sekcí), takže se můžete nechtěně pokusit o odeslání dat jedním kanálem více vláken.
Totéž platí pro jakoukoli síťovou komunikaci. Pokud jste měli například dvě vlákna, která se pokoušela sdílet jeden soket s připojením HTTP.
- Vlákno 1 odešle požadavek
- Vlákno 2 zadá požadavek
- Vlákno 1 čte bajty ze soketu a nevědomky čte odpověď z požadavku vlákna 2
Pokud jste zabalili všechny své transakce do kritických sekcí, a proto uzamkli všechna další vlákna na celý cyklus zahájení/potvrzení, možná budete moci sdílet databázové připojení mezi vlákny. Ale neudělal bych to ani potom, pokud opravdu nemáte vrozené znalosti protokolu JDBC.
Pokud většina vašich vláken nepotřebuje databázová připojení zřídka (nebo je nepotřebuje vůbec), můžete být schopni určit jedno vlákno, které bude provádět vaši databázovou práci, a nechat ostatní vlákna zařadit své požadavky do fronty do tohoto jednoho vlákna. To by snížilo režii tolika připojení. Ale budete muset přijít na to, jak spravovat připojení na vlákno ve vašem prostředí (nebo položit jinou konkrétní otázku na StackOverflow).
aktualizace: Abych odpověděl na vaši otázku v komentáři, většina databázových značek nepodporuje více souběžných transakcí na jednom připojení (InterBase/Firebird je jediná výjimka, o které vím).
Bylo by hezké mít samostatný transakční objekt a mít možnost spustit a potvrdit více transakcí na připojení. Ale prodejci to prostě nepodporují.
Podobně standardní API nezávislá na dodavateli jako JDBC a ODBC vycházejí ze stejného předpokladu, že stav transakce je pouze vlastností objektu připojení.