🚀 go-pugleaf

> la tabella (A) di fatto non viene mai modificata, viene solo letta.
Questo mi fa escludere qualsiasi meccanismo di locking e mi convince ancora
di pi� sulla mia prima proposta.


> l'utente si ritrova un elenco di prodotti da pagare, (da pagare anche
> parzialmente). Questo elenco viene generato da una query es:
>
> 2    caff�            2
> 3    Pane            6
>
> Da notare che il latte non c'� pi� in quanto gi� pagato totalmente.
> la questione �: se due utenti leggono i dati dei prodotti da pagare
vedranno
> le stesse informazioni, potranno selezionare gli stessi prodotti, ma al
> momento di dare ok solo uno di loro due deve riuscire a pagare ci� che ha
> selezionato.
Credo che tu possa risolvere solo con la query di update. Nella where della
update dovrai controllare se il prodotto � gi� stato pagato interamente, e
in questo caso l'update avr� luogo.
Cos� facendo, quando il primo utente tenta di pagare il Pane, riuscir�. Il
secondo utente invece si vedr� rispondere picche dal db perch� la where avr�
una condizione false che impedir� l'update.

Visto che le query al db vengono di default gestite in sequenza (il
meccanismo � pi� complesso ma grossolanamente si pu� approssimare ad un mero
accodamento), gestendo la giusta clausola where riesci ad evitare meccanismi
di locking o altre cose astruse.

Se il ragionamento dovesse essere pi� complesso, potrebbe convenire inserire
un 'middle tier' che si mette in mezzo tra i fruitori dei dati e il db. In
questo modo il middle tier saprebbe quale operazione fare e come eseguirla
perch� sarebbe lui stesso l'imbuto verso il db.

-- 
Raffaele Rialdi
UGIdotNET - User Group Italiano .NET  http://www.ugidotnet.org