Post by Carlo MilanesiPost by Andrea BarbagalloVorrei qualche consiglio sulla politica da adottare nello sviluppo di
un'applicazione per gestire gli accessi concorrenti di piu' utenti
allo stesso database nell'ambito di un'architettura di tipo
client-server. Il tutto, possibilmente, senza doversi necessariamente
legare ad uno specifico database.
Se chiarisci che cosa intendi per "politica" (spero non si parli di
elezioni del Parlamento italiano) forse qualcuno puo' rispondere.
Se con "database" intendi i dati, allora la tecnica comune e' usare un
sistema di gestione di basi di dati (DBMS). Tale sistema funziona come
processo server (ossia daemon, ossia service) sul sistema centrale.
Scusami: ho riletto il mio post ed ammetto di essere stato estremamente vago.
Provero' ad essere piu' chiaro.
Premetto che vorrei realizzare un'applicazione di tipo gestionale per aziende
(es. fatturazione e magazzino) che sia il piu' possibile indipendente dal tipo
di database utilizzato per contenere i dati ed il piu' possibile "scalabile".
Col termine scalabile intendo la possibilita' di poter funzionare sia
utilizzando un database dBase in monoutenza su un singolo pc, sia utilizzando
come database Access condiviso in multiutenza da due soli pc messi in rete, sia
collegandosi ad un server Oracle in uno scenario in cui, con la stessa
applicazione, centinaia di utenti della stessa rete di pc accedono al medesimo
database.
Tenendo presente questi obiettivi ideali (che probabilmente non sono
realizzabili del tutto ma da cui comunque non vorrei discostarmi troppo) mi
chiedo quali siano le tecniche di programmazione piu' efficaci per gestire il
problema degli accessi concorrenti di piu' utenti agli stessi dati.
So che spesso la tecnica usata e' quella di impostare un lock fisico sul record
quando l'utente inizia a modificarne i campi e mantenerlo fino alla pressione
del tasto "salva". In questo modo, se un altro utente prova contemporaneamente a
modificare lo stesso record, sul tentativo di impostare un nuovo lock si riceve
un errore dal database; tale errore viene gestito dal programmatore avvertendo
il secondo utente che il suo tentativo di modifica verra' annullato perche' i
dati sono gia' bloccati in scrittura. A me pero' questo approccio non piace per
i seguenti motivi:
1) viene meno al requisito di indipendenza da uno specifico database (o RDBMS)
poiche' le tecniche per impostare i lock fisici sui record variano da un
database all'altro (o sbaglio?);
2) su alcuni tipi di database la gestione dei lock a livello di singolo record
e' mal gestita o del tutto assente.
Un altro sistema a cui avrei pensato per risolvere il problema e' quello di
seguito descritto e consiste nel farsi una propria gestione dei lock (lock
"logici") evitando di loccare fisicamente il record e conservando in una tabella
l'elenco aggiornato dei record su cui si stanno effettuando delle modifiche.
Ecco i passaggi fondamentali di questa tecnica:
1) Quando l'utente inizia a scrivere sul campo di una maschera di input per
modificare un record viene, viene effettuato il controllo descritto al punto 2 e
- in caso di esito positivo - si inserisce un record in un'apposita tabella
(presente nello stesso db e dedicata esclusivamente alla gestione dei lock
logici) per segnare che un certo id utente sta bloccando in scrittura un record
con un certo id presente nella tabella X.
2) La modifica o la cancellazione di un record x vengono consentiti solo se,
nell'apposita tabella descritta al punto 1, non sono presenti registrazioni
contenenti l'id del record x. Nel caso in cui almeno una registrazione sia
presente, dalla stessa tabella viene letto l'id utente corrispondente al lock
riscontrato e si mostra all'utente un messaggio di errore del tipo "Permesso in
scrittura negato: l'utente Mario sta bloccando il record corrente".
3) Quando l'utente del punto 1 ha finito di modificare i campi e preme il
pulsante "Salva", i nuovi dati vengono scritti sul record e si elimina la
registrazione del lock logico dall'apposita tabella descritta al punto 1.
Tuttavia quest'ultima soluzione dovrebbe essere implementata da zero.
Mi chiedevo quindi se esistessero ulteriori tipi di approcci al problema e
magari delle tecnologie/tool/librerie gia' pronte per gestire gli accessi
concorrenti rispettando il piu' possibile gli obiettivi precedentemente enunciati.
Ciao
Andrea Barbagallo