Newsgroup: it.comp.lang.visual-basic
Titolo: dove un esempio applicazione con gestione della concorrenza ?

qualcuno puo' indicarmi un esempio di codice che descriva i metodi di
gestione della concorrenza per applicazioni che lavorano su db, su cui
accedono piu' utenti contemporaneamente ??.
sento spesso parlare di lock, e di transazioni ma non trovo documentazione.
ho scaricato anche mysql per provarlo, se qualcuno puo' indicarmi qualche
esempio di gestione db in multiutenza gliene sarei molto grato.
ciao a tutti.

 ha scritto

A parte il lock, ottimistico o pessimistico (se previsti da MySQL), di cui
io non mi fido per qualsiasi database, puoi pensare di crearti una tabella
nella quale registri i blocchi attivi.
Prima di iniziare un'operazione che presume un certo "controllo" (per
esempio l'incremento di un tuo contatore per assegnarne il risultato a un
nuovo documento), verifichi se nella _tua_ tabella esiste già un blocco
attivo, di "proprietà" di altro utente/client. Se no, lo depositi con tutte
le caratteristiche che ritieni opportune e, attenzione, verifichi
esplicitamente se è stato registrato (quello caratterizzato da quello
specifico utente/client). Se sì procedi, al termine della transazione lo
togli. Chiunque (utente/client) debba fare qualcosa di analogo (e magari di
identico) deve prima verificare se esiste, sempre nella tua tabella e per
altri utenti/client, un blocco attivo. Se sì, aspetta fintanto che scompare
(magari con un timeout), viceversa esegue quanto sopra descritto.
Ovviamente, in caso di interruzioni, è necessario prevedere una funzione
"speciale" che toglie tutti i blocchi.

ti ringrazio per la risposta.
avevo pensato ad una tabella aggiuntiva contenente l'utente, il record
bloccato, e la tabella del rec. bloccato, pero' se si usano db acces
l'aggiunta o l'editing di un record, blocca un'intera pagina di 2k e quindi
per una tabella (quella dei lock attivi) dove i record sono piccoli,
significa impedire ad un altro utente, l'inserimento del proprio record
segnalatore del lock o l'eliminazione di questo.
in piu' io mi sono avvalso di msde, ma mi hanno detto che microsoft sta'
vietando la distribuzione gratuita di questo anche ai possessori di vb pro;
quindi stavo analizzando la possibilita' passare le applicazioni ad altro
motore database, purtroppo effettivamente la doc. di mysql dice che questo
non supporta le transazioni se non usando innodb che non ho ben capito cosa
sia.
cmq ti sarei molto grato se tu potessi postare qualche esempio, visto che mi
sembra che tu abbia affrontato gia' il problema.

 sembra che tu abbia affrontato gia' il problema.
Un esempio, a parole:
Devo assegnare il numero a un documento, assolutamente univoco e
progressivo.
Per evitare che altri utenti possano fare, nello stesso momento (pochi
istanti) la stessa cosa:
La tabella che contiene il mio contatore si chiama TAB_CONTATORI
Decido di bloccarla per evitare che altri me la "freghino" nello stesso
momento, rischiando di usare lo stesso contatore.
Definisco la mia stringa di blocco, assolutamente convenzionale, per esempio
"TC"
*
Per sapere se la posso bloccare, prima verifico che non sia già bloccata da
altri.
Quindi cerco nella tabella dei blocchi se esiste un record con la "chiave"
TC.
Se sì, ciclo ogni poco sintanto che qualla chiave scompare. Al limite dopo
un certo tempo mi fermo con un messaggio del tipo "un operatore è andato a
bere il caffè, oppure ha dei problemi di pancia".
Se no, deposito il _mio_ record, ovvero TC-LUPO
Verifico se esiste un record con "chiave" TC-LUPO
Se sì ripeto  dal punto *
Se no, significa che il mio record è là e altri non possono fregarmelo,
perchè adottano la stessa tecnica.
Leggo liberamente il mio contatore, lo incremento e lo riscrivo. Lo metto in
una variabile in memoria.
Tolgo il record sulla tabella blocchi TC-LUPO
Procedo con il valore che ho nella variabile.
Nota finale: Tutti, nessuno escluso e anche in vari programmi devono fare (a
parità di zona "logica" da bloccare) esattamente le stesse cose.

 wrote:

Puoi provare PostgreSQL. Io non ho idea di come funzioni sotto
Windows, ma potresti provare.
Guarda 
http://www.it.postgresql.org/docs/faq-mswin.html
Ciao.
-- 
BSD is for UNIX lovers - linux is for Windows haters.

 perchč adottano la stessa tecnica.

 Procedo con il valore che ho nella variabile.
Variazione funzionale (mica tanto strana):
- Io devo creare sě un contatore univoco e progressivo,
    ma devo anche garantire l'integritŕ di tale contatore.
-ergo:
    - Ho una tabella associata apposita nella quale memorizzo
        le transazioni aperte sui numeri di protocollo.
    - Quando un utente crea un nuovo documento di un certo tipo,
        eseguo il tuo algoritmo di assegnazione,    _ma non assegno
        il numero definitivo al documento_ , bensě aggiungo il nuovo
        numero docuemnto alla tabella transazioni aperte.
    - Quando l'utente decide di salvare in via definitiva il docuemtno,
        allora tolgo dalla tabella delle transazioni aperte il numero
        del docuemnto che stava creando.
    - Se invece l'utente decide di darsi alla vita monastica, di
        compiere una strage perchč stufo della burocrazia in ufficio,
        di suicidarsi trascinando con se il personal giů dal balcone e
        via con amenitŕ del genere, il mio numero documento resta
        aperto nella tabella transazioni e viene reso disponibile al
        prossimo utente che deciderŕ di tentare la sorte creando
        un docuemnto simile...
Naturalmente la situazione si puň complicare (o semplificare) a
piacere al variare delle logiche di business specifiche.
Pensa ad esempio se, oltre a dover garantire l'integritŕ dei
protocolli tu dovessi garantire anche l'integritŕ delle date/ora
dei protocolli...
Spero d'essere stato chiaro e di aver contribuito a generare
ulteriori dubbi sulla complessitŕ delle logiche umane...   ;-)
ciao
ugo

         numero docuemnto alla tabella transazioni aperte.
Giustissimo. Solo che io, come te, non assegno affatto il numero quando si
dichiara di voler creare un nuovo documento, ma solo quando lo si registra.
In quell'occasione chiedo se accettare la numerazione progressiva o se
"imporre" un certo numero, deciso dall'utente. In questo secondo caso
verifico prima che quel numero non esista già. In entrambe i casi, eseguo
quanto brevemente descritto (anche per adeguare il contatore progressivo per
numero "preassegnato"), quindi in una fase di _sola_ attività di macchina,
senza interventi operatore.

 senza interventi operatore.
Ok.
Perfetto!
ciao
ugo

Questa teoria è molto bella e funzionale (se non sbaglio l'ho studiata in
facoltà col nome di Semaforo), ma mi sono sempre chiesto: non ci vorrebbe
anche una tabella di lock, per la tabella dei lock. E quindi anche un
semaforo per la tabella dei semafori per la tabella dei semafori e così via
all'infinito....
    Forse ho fatto una domanda cretina!!!

 all'infinito....
No, se si controlla anche subito dopo aver scritto (vedi il mio errata
corrige).
E' possibile, infatti, che nell'arco di pochi istanti due (o piů) clients
facciano la stessa cosa e la facciano lecitamente visto che non trovano
"semafori" di blocco. Se procedessero ... succederebbe il caos.
Ecco perchč č necessario verificare, dopo aver depositato la propria
"chiave", che non esistano chiavi di altri (esattamente come la prima
verifica). Se sě, significa che, a forza di spintoni, piů d'uno ha scritto.
In tal caso si cancella la propria chiave e si va a bussare nuovamente
ripetendo dall'inizio. Se no, si puň procedere perchč gli altri troveranno
la nostra chiave, sin dalla prima verifica e saranno loro ad aspettare.
Il tutto, ovviamente, se il motore fa il suo dovere. Ricordo che i programmi
DOS in rete Novell, pur applicando la stessa logica, a volte sbagliavano,
perchč la rete non garantiva la reale scrittura e la visibilitŕ dei nuovi
dati a tutti.

SORRY,
    non avevo capito... hai perfettamente ragione!!!
Bye

 Questa teoria è molto bella e funzionale
Funzionale mica tanto.
In realtà per un lock del genere si dovrebbero usare dei semafori di
"libero" e non di "blocco" altrimenti si rischia di avere dei blocchi
permanenti (es. il prog va in crash mentre blocca il record).
Ciao
--
using System.Gtk.Forms = "
http://www.neodatatype.net/windowsforms/sgf.aspx
"
mathParser = "
http://www.neodatatype.net
"
sitoComune = "
http://www.it-lang-vb.net
"

 permanenti (es. il prog va in crash mentre blocca il record).
Vero, ma, partendo dal presupposto che inizialmente è tutto libero, parrebbe
strano (e poco funzionale davvero) porre inizialmente a "verde" tutti i
semafori. E anche questo potrebbe cozzare con un blocco di sistema. Non per
niente, ma solo per casi eccezionali (tali devono essere considerati, guai
al contrario) si deve prevedere, come dicevo, una utility di sblocco totale.
In un caso e nell'altro.

 permanenti (es. il prog va in crash mentre blocca il record).
Ok: il ptoblema dei lock semaforici è classico.
Le soluzioni in genere variano dall'uso di demoni che
puliscono eventuali connessioni killed a timeout per
l'introduzione del data entry del singolo documento etc...
Non dimentichiamoci comunque che, come giustamente
ha rettificato Lupo, lo spostare dal momento del "new"
al momento del salvataggio l'assegnazione definitiva del
numero documento già elimina parecchie di queste problematiche.
ciao
ugo