Newsgroup: it.comp.lang.delphi
Titolo: Lock, mysql e idee...

Ciao a tutti, è tempo che non sviluppo in delphi, cause di forza 
maggiore da qualche anno sto sviluppando in e per Navision. :'(
Tornando a noi.. devo iniziare un progetto abbastanza grosso, e sto 
facendo analisi del progetto e cercando di capire che strumenti usare.
La base dati sicuramente mysql, e qui c'è il problema.
I famosi lock, mi sto documentando e ci sono parecchie correnti di 
pensiero su questa cosa, il "LOCK" che ho in mente io è di tipo 
pessimistico, quando un utente entra in edit di un record vorrei che 
quel record sia bloccato a tutti gli utenti in scrittura ma non in 
lettura. Per fare questo ho pensato di sviluppare un componente 
discendente dalle Ztable con qualche "piccola" modifica.
Pensavo di creare una tabella di lock, dove segnavo ogni volta che 
entravo in edit il record interessato, la tabella, l'utente.
Ogni volta che un utente deve entrare in edit interroga questa tabella e 
nel caso il suo record sia free entra in edit, se è bloccato verifica se
l'utente è ancora connesso (non potendo avere questo controllo lato 
server devo ipotizzare tutte le situazioni e gestirle) il componente 
restituisce il lock del record.. e poi da programma posso volendo 
mettere un timer che verifica questa cosa oppure lasciare all'utente
la possibilità di fare altro e ritentare dopo.
Follia pura?
Idee, commenti, suggerimenti?
;)

 pessimistico, 
Le ragioni di questa pessima idea?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Sono correnti di pensiero, io voglio che se un utente modifica
un record.. gli altri possono leggere, sapere che un utente X
lo sta modificando e non possono modificare finchè il primo
non ha finito.. perchè sembra così aliena questa idea?

 non ha finito.. perchè sembra così aliena questa idea?
Perché non è così che si lavora in un contesto multiutente, specie se in
un progetto grande, per il quale presumo, quindi, siano ipotizzate molte
postazioni. Ma a prescindere dal numero, è bene che gli utenti lavorino in
modo ottimistico: si prova comunque a compiere l'operazione e al limite il
db sputa indietro la richiesta di consolidamento dei dati. I database
normalmente gestiscono bene queste situazioni, in modo sicuro. Il lock
pessimistico è troppo legato al passato dei db file-based (dove era
possibile fare solo così) e troppo limitante per un DBMS. Studia bene come
vengono adoperate le transazioni nel tuo database e, se puoi, adotta un
modello ottimistico.


 modello ottimistico.
Mi sto documentando sulle transazioni.. ma voglio farti una domanda...
se ho 2 utenti che sono sullo stesso record..facciamo di anagrafica, uno 
modifica alle 14.00 il cap, e un altro modifica anche lui il cap alle 
14.02, che fine fa il cap del primo?
Magari č un esempio stupido, anche togliendo il magari ;), perň rende 
l'idea.

 l'idea.
Ovviamente il cap del primo viene perduto..
E aggiungo che se il primo che modifica il cap apre il record in edit, ci
scrive 99999, poi si dimentica di fare il save e se ne esce coi colleghi a
bere un buon caffè.. con l'approccio pessimistico nessuno sarebbe piu' in
grado di modificare quell'anagrafica fintanto che il collega ritorna dal
bar.
Il modello di concorrenza di accessi client/server via SQL più in uso oggi
è quello ottimistico. 
Ciao
-- 
Morde

 14.02, che fine fa il cap del primo?
Dipende da cosa intendi per "modifica": se per "modificare" intendi 
"cambiare il valore del campo e salvarlo", rimarrà solamente l'ultimo, 
ma questo dovrebbe avvenire anche nel caso di "blocco dei record".
Ad ogni modo, se stai cercando di smontare per principio l'efficacia di 
lavorare con un sistema "ottimistico" (ben gestito, ovviamente) e basato 
su database client/server, magari con l'uso del componente 
*TClientDataSet* per la gestione di una cache locale, avrai vita dura. :-)
L'unica cosa che dovresti stabilire, secondo me, è se ti va o meno di 
approfondire la questione e abbandonare un approccio "pessimistico", 
semplice ma un po' limitativo, in favore di quello "ottimistico", che 
richiede qualche sforzo in più, ma nemmeno così tanti (il suddetto 
componente *TClientDataSet* e il "compagno di viaggio" 
*TDataSetProvider* gestiscono - quasi - automaticamente ogni aspetto).
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 *TClientDataSet* per la gestione di una cache locale, avrai vita dura. :-)
Mi vado a documentare.. però è una cosa che non mi è mai entrata in 
testa la versione ottimistica.. quando penso agli utenti la vedo
sempre pessimistica la situazione ;)

 è quello ottimistico. 
Lo so, ed è questo che non capisco, non sempre la cosa più utilizzata è 
quella più corretta.. o sbaglio? ;)
Nella mia esperienza, quando avevo fatto alcuni programmi "pessimistici"
i dati non si perdevano.. ok c'era il caso del caffè, ma rientra 
tranquillamente nella casistica dell'ottimistico, quella in cui dici non
andranno tutti a modificare quel record no?...
Mentre da qualche anno uso navision, la parte dell'interfaccia secondo 
me va molto ad abitudine, ma vedo questo sistema, che ha tutti i campi
sempre modificabili e tutti gli utenti spesso premono tasti senza
accorgersi e modificano campi.. a volte anche in concomitanza con altri,
poi navision si popola le tabelle successive prendendo i dati dalle 
prime e uno deve andare a correggere.. magari dopo diversi processi.
Vorrei capire perchè tutti usano l'ottimistico, forse perchè è + 
semplice considerare che va sempre tutto bene saltando un po di controlli?

 nessuno può scrivere su quel record, quindi nessuno può perdere dati.
Ti stai assumendo una responsabilità che normalmente viene delegata al
database: è ques'ultimo che deve assumersi la responabilità di non perdere
i dati.
Perchè non rispondi al mio "use case" dell'utente che abbandona la
postazione col record in edit...Che fai, blocchi il lavoro di tutta
l'azienda per colpa di un comportamento irresponsabile di un utente? (Che
ovviamente deriva da una tua scelta progettuale, perche' sei tu che glie lo
permetti col modello del lock pessimistico)
Ha ragione Laforgia: il modello di lock pessimistico è legato al mondo file
server, che oggi è soltanto di nicchia e obsoleto.
Ciao
-- 
Morde

Morde ha scritto:

sicuramente il comportamento di un utente di questo tipo blocca il 
lavoro, in teoria se si progetta bene si potrebbe ipotizzare questa
situazione sbloccato il record se si passa in questa casistica (pc 
inattivo per troppo tempo) però qui insorge il rischio che l'utente
che è andato a bere il caffè perde i suoi dati.. ma a questo
punto mica puoi inseguire tutti gli utenti con un fazzoletto quando
gli cola il naso... o no?

 gli cola il naso... o no?
http://www.microsoft.com/italy/msdn/risorsemsdn/security/editoriale/sicurezza_dati.mspx
Ciao
ACSH


 sempre pessimistica la situazione ;)
Sicuramente ci sono degli accorgimenti da prendere, o meglio ci sono 
delle configurazioni da fare (se si parla di componenti Delphi per 
l'accesso ai dati). Se usi un blocco pessimistico e poi implementi 
chissà quali accrocchi per gestire il caso di blocco prolungato e 
ingiustificato del record da parte di utenti, è senz'altro meglio 
sfruttare le logiche di funzionamento "ottimistiche" invece di hackerare 
quelle "pessimistiche", sia in termini di semplicità, comprensione ed 
efficacia, secondo me. :-)


 
http://www.microsoft.com/italy/msdn/risorsemsdn/security/editoriale/sicurezza_dati.mspx
Gran bella guida, mi ha chiarito le idee..
ora devo trovare la gestione più corretta e ottimistica possibile ;)

 14.02, che fine fa il cap del primo?
Stai ipotizzando un "lost update", che con le transazioni è controllabile.
Scenario: l'utente A accede alla base dati alle ore 13.50 e conferma la
modifica del cap alle 14.00. L'utente B accede alla base dati alla stessa
ora di A e conferma la modifica del cap alle 14.02. Quando B va a cercare
di consolidare i suoi dati, il sistema si accorge che i dati presenti nel
database sono variati rispetto a quelli letti da B alle 13.50, perché
consolidati nel frattempo da A, e quindi non consente a B di consolidare.
Si può chiedere, a questo punto, se si vuol ricaricare la nuova situazione
dell'utente, che B non conosce.
Ricaricare i dati è consigliabile, perché A può aver modificato delle
informazioni che sono determinanti per le modifiche di B. Quest'ultimo,
difatti, potrebbe accorgersi che le modifiche che voleva fare, a questo
punto, non sono più necessarie. Questa gestione del conflitto tra utenti è
automatica, con MIDAS/DataSnap. Si può anche modulare il comportamento,
consentendo, per esempio, di far passare, per B, la sola modifica dei
campi non toccati da A.
