Newsgroup: it.comp.programmare
Titolo: Gestione accessi concorrenti al database

Ciao a tutti.
Vorrei 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.
Grazie per l'attenzione
Andrea Barbagallo

 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.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

Carlo Milanesi ha scritto:

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

 Andrea Barbagallo

 record e' mal gestita o del tutto assente.
A meno che tu voglia sviluppare un DBMS, tutto questo e' reso inutile 
dal fatto che e' gia' implementato all'interno dei DBMS che supportano 
le transazioni.
Se all'interno di una transazione leggi un record, il record viene 
automaticamente bloccato, e viene sbloccato quando si conferma (commit) 
o annulla (rollback) la transazione. Anche Microsoft Access supporta le 
transazioni.


> .... mai sentito parlare di RDBMS .....
Mai sentito parlare di quoting?
http://digilander.libero.it/ifst/html/Quoting.html
Stefano.