Giusto per precisione:
il DBMS/DB server NON CHIUDE LA CONNESSIONE
E sempre responsabilità del client creare la connessione, chiuderla, cosi' come creare la transazione e chiuderla con commit/rollback.
poi' c'e' il discorso del connection pool, che si dovrebbe sempre usare, che fa sì che la connessione non venga realmente chiusa ma solo messa nel pool in attesa del prossimo utilizzo.
Ma questa e' un'altra storia.
Per esperienza, non sempre le strutture dati adibite alla gestione della connessione al dbms si accorgono se la connessione tcp/IP e' stata interrotta. se ne accorgono di sicuro durante l'esecuzione del primo statement dopo l'interruzione della stessa.
Ma questo dovrebbe essere un fatto mooooooooolto raro. Se accade con regolarità serve
capire perche' avviene
se non c'e' modo di evitarlo, serve un meccanismo intelligente di riconessione automatica e riesecuzione dello statemenrlt.
Complicato anche se non difficile .
Attenzione a non far “confusione” con le connessioni HTTP che funzionano proprio in questo modo: il client apre la connessione, fa una richiesta, il server risponde e la chiude.
Anche qui, non e' detto che la chiuda veramente, magari la connessione rimane aperta per un certo tempo per permettere la comunicazione in modo piu' efficiente
Il discorso con il file e' TUTTA un'altra storia, e non centra nulla con una connessione TCP/IP: la possibilita da parte di UN'ALTRO client di leggere o modificare un file dipende dal SO e dai permessi durante l'apertura da parte del PRIMO client. Si puo' fare ma anche no.
Insomma e' come confrontare mattoni con biondine in spiaggia: si puo' anche fare, ma di sicuro i mattono non sono un valido sostituto ;-)