[Gfoss] Aprire postgres verso l'esterno con indirizzo IP statico.

[Andrea Peri]

>Gli stessi problemi comunque vanno considerati su WAN o LAN (non c'e'
>scritto da nessuna parte che la LAN sia 'affidabile'...) quindi

In effetti non e' scritto da nessuna parte.
Pero' dipende da cosa si intende per affidabilita'.

Se per affidabilita' si intende il fatto che non si rompe cosi' di frequente
siamo daccordo che rete internet e rete interna sono parimenti affidabili.
Ma se si intende per affidabilita' la capacita'di far arrivare un pacchetto
a destinazione senza che contenga degli errori non correggibili. Allora pari
non sono.

Infatti si sa' benissimo che in un collegamento in adsl si trasferiscono i
pacchetti con una certa velocita', mentre in un collegamento con una rete
interna di tipo gigabit si trasferiscono con velocita' notevolmente
superiore.

Altrettanto e' scritto che piu' si aumenta la velocita' di trasferimento e
maggiore e' la probabilita' di errore sui pacchetti trasmessi.
E poiche' i confronti di affidabilità si fanno a parità di condizioni, cio'
implica che si devono fare a pari velocita' di trasferimento.

Per cui il fatto che se una viaggia a una certa velocita', e piu' veloce non
puo' andare se non si vuole cominciare a ricevere roba sbagliata a go-go',
implica di per se' che e' meno affidabile.

Comunque, come dicevo, la cosa migliore e' provare.

Magari se poi viene condiviso i risultati,
anche io sono interessato a capire se l'attuale qualita' dei collegamenti
adsl consente un uso "decente" di un collegamento client-server.

> il problema
>principale sono i timeout di connessione e connessi a questi il problema
>di garantirsi contro modifiche parziali (-> inconsistenti) del DB.

Il problema e' sempre lo stesso.
Se lo si vuole vedere a livello applicativo ignorando il fenomeno fisico che
ne e' la causa.
Si prova una strada o se ne prova un'altra fino a trovarne una che sembra
minimizzare il problema.
Se si parte analizzando la causa che fa' nascere il timeout. Si puo' capire
meglio quale sia la soluzione migliore.

>strettamente transazionale nell'effettuare le modifiche (con rollback
>automatico in caso di mancato commit esplicito).


Mica e' detto che sia la soluzione migliore.
Comunque , in generale ognuno  ha le proprie opinioni e io ho le mie.

Se ad esempio la connessione va in timeout ogni 3 minuti, il tuo db tollback
in continuazione e te non riesci a portare a termine manco una riga di
lavoro.

Per questo quando si spedisce roba via internet si fa' ricorso a uno strato
middleware.
Per separare la parte a bassa affidabilita' da quella ad alta affidabilita'.
La parte del client che si collega al dbms la fa' lo strato middleware che
sta' nella stanza accanto al server dbms
e viaggia su una bella rete in gigabit a bassa probabilita' di errore.

Ovvero la connessione con il db non e' diretta con un client che sta'
dall'altra parte del mondo.

Ma se ci si trova nella condizione di dover per forza fare un collegamento
diretto di tipo client-server tra un qgis e un postgres via internet, farei
in maniera differente da come dici te.

Anche perche' io guardo il problema dal punto di vista di minimizzare i
problemi generati dalla connettività.
Infatti secondo me, un forte ricorso alle transazioni, esporrebbe al rischio
di non riuscire mai a completare un lavoro.

Farei piuttosto ricorso a una configurazione autocommittante. In modo da
mettere al sicuro ogni singolo pacchetto arrivato intatto sul dbms.  (e
sperando che ce ne siano abbastanza).
Questo chiaramente richiede tutta una serie di impostazioni strutturali
pensate ad hoc sulla struttura della base dati.
Tipo evitare di impostare delle relazioni di vincolo tra tabelle distinte.

Ciao,


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100515/0deac5a8/attachment.htm>