Violazione concorrenza in document orientation

[f.delsordo]

Dopo un'assistenza abbiamo scoperto che il document, prima del salvataggio, non verifica che i dati letti dal document siano ancora gli stessi su db.

Ci sembra opportuna che questo venga fatto, soprattutto visto che è una funzionalità già presente nei panel Table Oriented che bloccano il salvataggio notificando all'utente una violazione di concorrenza.

[r.bianco]

Per la DO esiste un servizio apposito di gestione dei lock.

Immagine.png (18.14 KiB) Viewed 2870 times

Altrimenti è possibile crearne uno prorio grazie agli eventi globali (noi abbiamo fatto così).

[f.delsordo]

Grazie per la risposta. Noi utilizziamo già la gestione dei lock da parte del framework, attraverso il check da te indicato. In questo modo il framework impedisce le modifiche se un'altro utente/sessione (in base al codice scritto nell'evento di getLock) sta lavorando, nel senso che sta modificando i dati senza ancora averli salvati.

Quello che il framework non fa è avvisare un utente che i dati che sta modificando sono cambiati dall'ultima volta che sono stati caricati.

Ad es.:

utente 1 apre la videata

utente 2 apre la videata

utente 1 modifica i dati e salva

utente 2 modifica i dati e salva ( in questo momento mi aspetto che il framework blocchi ed avvisi utente 2 che in realtà i dati che sta modificando sono stati cambiati )

[a.rughi]

Esatta, è quello che anche secondo ma manca e deve essere inserito.
Come detto da Francesco questo problema di "dirty read" è gestito da InDe per i panel semplici senza DO, ma NON per i document che nascono appunto per le gestioni evolute e solide delle applicazioni.

[t.simoncini]

Voto la proposta di modifica anche io, anche se ho dei dubbi sulla fattibilità "sempre e comunque" su classi con master query complesse su più tabelle.
Resta comunque una funzionalità estremamente interessante.
Per i casi strani si potrebbe inserire un evento sulla classe e(s. OnCheckAlreadyModified o qualcosa del genere) dove poter inserire una logica personalizzata.
La butto lì.

[r.bianco]

Interessante.

[a.maioli]

Per ottenere il "lock ottimistico" a livello di documenti è sufficiente inserire un evento globale a livello di before save e fare il controllo richiesto.
Noi non lo abbiamo previsto by design perchè rileggere i record prima di scriverli causa perdita di performance e non è difficile da aggiungere per chi desidera implementarlo comunque.
In ogni caso la gestione "preventiva" dei lock a noi sembra migliore nei casi "normali" perchè è quello che l'utente si aspetta.