Newsgroup: it.comp.lang.delphi
Titolo: Record Lock Conflict

Salve, sto utilizzando firebird e mi si ï¿œ posto il seguente problema su 
uno stesso database:
Programma A: legge e scrive su uno o piï¿œ record
Programma B: legge e scrive su uno o piï¿œ record ma ha prioritï¿œ su A.
In pratica B deve poter sempre scrivere nel record che A puï¿œ avere anche 
in modalitï¿œ di edit.
Al momento entrambe le transazioni sono con le seguente impostazioni:
   read_committed
   rec_version
   nowait
C'ï¿œ qualche impostazione che posso utilizzare per avere il funzionamento 
desiderato?
Pensavo che il programma B controlli che il record sia in stato di lock 
ed eventualmente effettua un unlock del record; oppure l'approccio ï¿œ 
completamente diverso?
Sto utilizzando Firebird 2.1 con i componenti IBX su Delphi 2007
Grazie in anticipo
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 in modalità di edit.
xche?
A.

 Sto utilizzando Firebird 2.1 con i componenti IBX su Delphi 2007
Concentrati sui componenti IBX per le proprietï¿œ dell'Isolation level.
Potresti risolvere in maniera rapida impostando la connessione 
prioritaria (B) con lock sul record, lasciando la meno prioritaria cosï¿œ 
com'ï¿œ.
Se non dovessi/potessi uscirne, allora devi risolvere la cosa via 
software gestendo una tabella di semafori dove viene mappato l'ID della 
riga in editing e chi la sta editando.
tabella semafori:
PK record, ID utente, timestamp inizio editing
ogni volta che un utente vuole editare un record, verifica la tabella 
semafori e agisci di conseguenza.
Il timestamp serve a impostare un tempo massimo di editing, dopo il 
quale puoi decidere se sbloccare il record.
Quando un utente vuole salvare, controlla nella tabella semafori se il 
suo record ï¿œ ancora disponibile. Se non lo ï¿œ piï¿œ, avvisa che il record 
non ï¿œ piï¿œ disponibile oppure e' in uso per un altro utente con prioritï¿œ 
maggiore.
L'utente prioritario puï¿œ editare ogni record, quello meno prioritario 
deve rispettare il semaforo (se esistente)in tabella.
vado di fretta questo e' tutto quello che posso dirti per ora.
ciao
-- 
morde
D5,D6,D7
QT 4.7.0 - MingW- QT Creator 2.1


Perch� le informazioni di B hanno priorit� su quelle di A. Le 
informazioni che scrive B possono sovrascrivere quelle di A senza 
effettuare alcun permesso.
Fabrizo



Forse la soluzione ï¿œ quella di mettere tutto in una o piï¿œ tabelle di 
buffer il contenuto che il programma B deve riversare nel db e poi 
salvare i record correttamente aspettando (anche con l'uso di semafori) 
che l'operazione sia fattibile.
Grazie per le dritte
Fabrizio.


 modalità di edit.
Non ho capito questa. Perche' devi lasciare il record in edit. non sei 
mica in excel
Kd

> Perch le informazioni di B hanno priorit su quelle di A.
..quindi il funzionamento si basa sulla violazione del presupposto
fondamentale di un db client/server?
uhm...
A.

 che l'operazione sia fattibile.
Da quel che intuisco sembra dunque che la "fretta" di uno dei due 
processi di scrivere i dati sia legata al fatto che non è possibile 
attendere più di "molto poco" per iniziare e porre a termine 
l'operazione, pena la perdita di dati.
Ad esempio in una situazione in cui tali dati arrivano in streaming da 
un dispositivo ("streaming" è qui un concetto generico, potrebbe essere 
anche una seriale)
Se ho capito giusto, allora il "forse" di prima va sostituito con 
"sicuramente": tu DEVI predisporre un buffer ed utilizzare poi con calma 
un processo per caricare dal buffer i dati in un ambiente transazionale 
puro; a quel punto l'operazione è fattivile nel senso che le transazioni 
ti aiutano a farlo in modo trasparente.
-- 
byez
Piero


Sicuramente ho scritto male. In effetti non e' una vera e propria 
priorita' ma i dati di B sono dei dati provenienti da un dispositivo 
esterno che fornisce dei dati certi ed ufficiali. L'operatore inserisce 
dei dati dedotti, quindi i dati provenienti da B hanno priorita' in 
questo senso.


 mica in excel
Perche' quando un utente effettua delle modifiche i componenti 
utilizzati impostano il record in modalita' di edit fino a quando 
l'utente non "salva".



Si esattamente i dati provengono da una seriale e cmq sono dati 
"ufficiali" e certi mentre quelli inseriti dall'operatore sono dei dati 
"temporanei" e possono essere sovrascritti.
Il problema è accaduto proprio quando si effettua un aggiornamento da 
seriale e l'operatore stava inserendo dei dati.



usare le ttable sui database sql e' una pessima idea.
Kd

 seriale e l'operatore stava inserendo dei dati.
Hmm.. il problema assume ora una connotazione differente.
Al di là del fatto che converrebbe utilizzare dei meccanismi più consoni 
ad un Database transazionale (evitando dunque l'uso di TTable e di lock 
record diretti), ci sono considerazioni puramente applciative.
Io spezzerei il problema in questo modo:
1. Se l'attività della seriale è tale per cui non può sempre aspettare 
il suo turno, è necessario utilizzare un buffer per non perdere quei 
dati; il buffer può essere fatto in vari modi, anche in una tabella 
"privata", cioè una tabella in cui la seriale non fa che appendere 
record, ed un processo interno all'applicazione invece li "preleva" e li 
"marca" come elaborati.
PROBLEMA: non ricordo se il FB esegue un lock sul record o sulla pagina 
durante le transazioni, pertanto ci possono essere dei side effect per 
cui io applicazione tramite il controllo della transazione di fatto 
blocco anche record che non mi interessano, ed impedisco alla seriale di 
scrivere subito.
Ma lo vedo un po' raro
2. A quanto pare non è un semplice problema di tempi, ma piuttosto di 
"affidabilità" di chi scrive.
In prima istanza sembra facile, dato che se uno dei due "scrittori" è 
sempre affidabile ed un altro non lo è mai, significa che quando lo 
scrittor affidabile ha scritto, quello non affidabile non può modificare 
più i dati scritti.
Questo si risolve con una colonna che possiamo definire "dato_certo", un 
valore logico che vale Vero o Falso a seconda di chi ha modificato il 
record l'ultima volta.
E' chiaro allora, che in qualunque momento, il processo "affidabile" può 
sovrascrivere dati, mentre quello non affidabile non può.
3. Se tutto ciò risponde a verità, allora, è sufficiente (hehe) 
abbandonare proprio il paradigma da te usato, che se non ho capito male è:
   lock recoed
   edit "umano", dunque di durata indefinita (anche minuti, in caso di 
pausa caffè)
   unlock record
E' chiaro che se il processo affidabile tenta di scrivere il dato 
affidabile mentre il record è bloccato non funziona, ed è questo che va 
risolto.
Supponendo anche che tu fossi in grado di violare le regole del DB e 
permettere al processo affidabile la scrittura anche durante l'edit da 
parte dell'utente, ti trovi il problema che, se non fai un refresh dei 
dati, non sai che intanto il record è diventato non modificabile 
dall'utente. Dunque comunque devi abbandonare questo paradigma in favore 
di un'update differito (solitamente chiamato cached update).
Abbandonare il sistema precedente a favore di un "Cached Update" o come 
lo vuoi chiamare, in cui prima dell'ApplyUpdates si controlla che il 
record intanto non sia diventato affidabile per conto suo è sicuramente 
possibile, e rende il sistema un po' più robusto ed elegante.
Ma andrebbe comunque bene anche che il processo "affidabile" (che legge 
i dati dalla tabella buffer) se non riesce ad effettuare la modifica si 
mette in attesa; eventuali timeout (che ci sono!) devono lasciare il 
record temporaneo in stato "non ancora elaborato", così alla peggio 
l'elaborazione avviene dopo un po' ma in maniera corretta, nel senso che 
il processo "affidabile" può e deve sempre sovrascrivere i dati dell'utente.
HTH
-- 
byez
Piero