[SQL] MySQL, PostgreSQL e FireBirdSQL: Quale scegliere?

[Mantis-89]

Originariamente inviato da cdimauro

Lascia perdere. Mi piange il cuore a vedere un database trattato così.

Tranquillo non lo voglio mica fare per ogni update
Come detto voglio solo impedire ad un utente di andare in modifica di un record quando è già in uso.

[Mantis-89]

Originariamente inviato da cionci

Per quel record ok, ma se un utente deve usare i dati contenuti in quella tabella per una query... La query è invalidata se contiene uno dei record bloccati ?

No

[cionci]

Ok, quindi vuoi bloccare solo modifica contemporanea.

Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.

[gugoXX]

Detta cosi', e' la gestione normale, proprio normalissima, di un database (uin database vero pero', gli altri non garantisco).
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.

[Mantis-89]

Originariamente inviato da cionci

Ok, quindi vuoi bloccare solo modifica contemporanea.

Imho potresti gestire bene con i trigger l'effettiva cancellazione dei lock in caso di timeout.

In che senso? Fare il controllo sullo stato della connessione dell'utente che lo tiene in lock ed eventualemnte sbloccarlo in caso direttamente da Trigger?
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?

[Mantis-89]

Originariamente inviato da gugoXX

Detta cosi', e' la gestione normale, proprio normalissima, di un database (uin database vero pero', gli altri non garantisco).
Apri una transazione, modifichi un record, tieni aperta la transazione.
Tutti gli altri potranno entrare in lettura su tale record, e aspetteranno invece se dovessero tentare una scrittura.
Fino a che la transazione non restera' aperta.

Il record lo modifico solo prima di chiudere la transazione l'utente lavoro sulla copia in locale. E in questo modo potrei avere dei dead lock.

[gugoXX]

Originariamente inviato da Mantis-89

Il record lo modifico solo prima di chiudere la transazione l'utente lavoro sulla copia in locale. E in questo modo potrei avere dei dead lock.

Se costruisci la tua gestione dei lock, che dovesse replicare il comportamento di cui sopra, avrai tanti deadlock quanti ne avresti avuti se la gestione dei lock l'avessi lasciata al solo database.

Inoltre pensa, p.es. se l'applicazione client si schianta (terminologia tecnica informatica, soprattutto quando c'e' un database coinvolto).
Nel caso di gestione demandata al database, la transazione viene forzata chiusa con rollback, e il record e' di nuovo libero.
Nel caso di gestione tua invece devi prevedere e gestire questo evento, altrimenti nessuno potra' piu' accedere al record.

[Mantis-89]

Come ho detto:
-Il lock si applica solo per aprire in modifica il record e non influisce il funzionamento di qualsiasi altra query
-Se il lock fallisce controllo che che la connessione dell'utente che sta eseguendo il lock non sia "morta" e in tal caso rimuovo tutti i lock per quell'utente (dall'applicazione o da trigger come mi suggeriva cionci)

So che forse non è la soluzione migliore però intanto voglio provare a seguire questa strada che come tutte le altre possibili ha i suoi pro e i suoi contro e le sue limitazioni.

[Mantis-89]

.....ma FireBird non supporta le colonne autoincrementanti...?

[cionci]

Originariamente inviato da Mantis-89

In che senso? Fare il controllo sullo stato della connessione dell'utente che lo tiene in lock ed eventualemnte sbloccarlo in caso direttamente da Trigger?
Beh si può fare, si tratta sempre di decidere quanto codice lasciare sul database e quanto sull'applicazione. Di sicuro con i trigger è più veloce (e magari anche più sicuro) però ogni database avrebbe un trigger scritto diversamente giusto?

Esattamente. Ad esempio potresti mettere un trigger sulla rimozione dell'utente dalla lista degli utenti loggati. Se viene rimosso allora tutti i lock vengono rimossi automaticamente.
Per la rimozione di un utente in timeout puoi fare così: fai in modo che tutti gli utenti debbano fare un UPDATE del timestamp nella tabella degli utenti loggati ogni tot secondi (ad esempio 60 secondi).
Metti un trigger su UPDATE e su INSERT con relativa stored procedure che elimina tutti gli utenti il cui timestamp è più vecchio di 70 secondi. Così automaticamente lanci la rimozione dei lock di quell'utente.

[Mantis-89]

E' praticamente come l'avevo pensato (anche se vorrei che i tempo dopo cui un client è considerato morto sia almeno 2,5 volte il tempo di aggiornamento). Potrei lavorare sui trigger di inserimento della tabella delle connessioni utente e quella dei record in lock.

A lavoro quando ho parlato di un timer per gestire gli utenti connessi mi hannno guardato male tu che ne dici invece?

[cionci]

Originariamente inviato da Mantis-89

A lavoro quando ho parlato di un timer per gestire gli utenti connessi mi hannno guardato male tu che ne dici invece?

In che senso ?

[Mantis-89]

Per fare l'update dovrò avere un timer, mi hanno detto che porta via troppe risorse e che non dovrei usarlo.

[cionci]

Originariamente inviato da Mantis-89

Per fare l'update dovrò avere un timer, mi hanno detto che porta via troppe risorse e che non dovrei usarlo.

L'update di cosa ?

[Mantis-89]

Originariamente inviato da cionci

fai in modo che tutti gli utenti debbano fare un UPDATE del timestamp nella tabella degli utenti loggati ogni tot secondi (ad esempio 60 secondi).

[cionci]

Non mi sembra che un thread che si sveglia ogni 60 secondi ed effettua una query sia un'operazione costosa. Anzi...
Chiedigli meglio le motivazioni.

[Mantis-89]

E' quello che ho pensato anche io... proverò a chiedere meglio.
Grazie comunque.

PS: Ora sto provando PostgreSQL e mi ha colpito positivamente

[cdimauro]

Originariamente inviato da Mantis-89

.....ma FireBird non supporta le colonne autoincrementanti...?

No, e uno dei motivi è proprio quello di evitare il lock della tabella a cui sono legati.

Si usano i generatori o sequenze (quest'ultimo è il termine usato nello standard SQL-9x e SQL-2003) che ti permettono, tra l'altro, di avere un controllo più fine.