Das ist so nicht nötig, der Thread startet in jedem Fall frühestens, wenn alle Konstruktoren abgeschlossen wurden.
Ich vermute das die Exception im Konstruktor eigentlich nur ein Folgefehler und die Ursache viel früher zu suchen ist.

Problem: Es wird ein Thread erzeugt, der Zugriff auf eine Connection nimmt, die ihm nicht gehört.
Es existiert keine Kontrolle welche Threads existieren, die derzeit mit dieser Connection arbeitet.
Der Zugriff "Sql.Connection.InTransaction" kann schon eine Zugriffsverletzung auslösen.
Es müsste zumindest unmittelbar ein StartTransaction folgen und beides mit einer CriticalSection gekapselt werden.

Insgesamt scheint mir die Konstruktion ziemlich fehleranfällig.
Ich würde die Anwendung im Prinzip so aufbauen:

[1.Liste der wartenden Aufgaben]
-> 1.Thread der jeweils eine Aufgabe per TCP/IP abarbeitet und mit dem Ergebnis in 2.Liste stellt (hat mit DB nichts zu tun)
[2.Liste der wartenden Aufgaben]
-> 2.Thread der jeweils die Datenbankarbeit für eine Aufgabe erledigt und diese mit neuem Termin wieder in die 1.Liste stellt
(hat eigene DB-Verbindung, die niemanden sonst etwas angeht)

Beide Threads existieren permanent und warten, wenn keine Aufgabe ansteht.
Zugriffe auf die Listen müssen natürlich gekapselt werden.