24 messaggi dal 01 febbraio 2017
BrightSoul ha scritto:

...
Se supporti l'editing collaborativo in tempo reale, l'utente vedrà che qualcun altro sta modificando una casella senza che debba attendere il salvataggio per saperlo.
Con la concorrenza pessimistica poni un blocco alla produttività degli utenti. Spesso, utenti che modificano in maniera concorrente la stessa anagrafica lo fanno per motivi diversi: c'è chi modifica un errore nella ragione sociale, c'è chi aggiunte un estremo di pagamento, c'è chi cambia la classe del cliente e così via, secondo la propria mansione. Per questo motivo dovresti spezzare la mega-form in parti più piccole e, in caso, bloccare solo quelle. Le task based UI hanno proprio il compito di assecondare il comportamento degli utenti con comandi specifici, anziché avere 100 campi e un tasto "Salva" alla fine. Questo è un esempio di Task Based UI, in cui i pochi cambi che compongono l'anagrafica dell'utente viene spezzata in 3 parti, ciascuna con il proprio comando di aggiornamento.
https://jsfiddle.net/cg7ggmo1/1/


ciao,
Moreno
Modificato da BrightSoul il 23 novembre 2017 20.07 -


Grazie del suggerimento, vado ad approfondire il link che mi hai postato. Comunque è un modo per alleviare il problema e non risolverlo.
24 messaggi dal 01 febbraio 2017
bryger ha scritto:

Con la concorrenza pessimistica poni un blocco alla produttività degli utenti.
è lo stesso principio dei sistemi di versionamento, se blocchi la risorsa quando un utente ci sta lavorando nessuno può utilizzarla finchè non l'ha rilasciata e questo a volte può richiedere anche diverso tempo, in una struttura distribuita, magari anche delocalizzata, è ovvio che questo sistema non è utilizzabile; se invece il gruppo di lavoro è piccolo o piccolissimo può essere una strategia attuabile; poi c'è da dire che se un certo record viene bloccato da un utente al momento dell'apertura cosa succede se per qualche motivo abbandona la postazione e il software rimane fermo su quella funzionalità? (cosa molto frequente in certi casi) bisogna che qualcuno intervenga manualmente a 'sbloccare' la situazione altrimenti nessuno potrà più lavorare su quel record, quindi anche questo mi sembra poco sostenibile.

Attenzione ho detto di bloccare in sola visualizzazione, significa che è vero che nessuno può variare il record (in quel momento), ma chiunque può visualizzarne la versione corrente, fin quando non viene sotituita dalla nuova versione salvata. Quindi non viene bloccato il lavoro degli altri utenti, che possono continuare a visualizzare i dati, fare stampe, statistiche e così via ...

Il problema dello "sblocco" in caso di terminale abbandonato, o anche se cade la sessione mentre lavori, ad esempio in rete locale, o in WIFI , si risolve semplicemente con un timer.
Aggiungi un controllo Timer sulla Form e se non viene premuto nessun tasto (o mosso il mouse), parte il conto alla rovescia. Alla fine se nessuno risponde, chiude tutto e libera le risorse, molto semplice (e già implementato e funzionante).
;-)
136 messaggi dal 22 gennaio 2017
Contributi
Ho seguito il thread molto volentieri perchè è una discussione che nessuno più si pone.
Il lock pessimistico porta con se molti problemi.
Scrivo il mio punto di vista in modo sparso:


Il problema dello "sblocco" in caso di terminale abbandonato, o anche se cade la sessione mentre lavori, ad esempio in rete locale, o in WIFI , si risolve semplicemente con un timer.

In caso di crash dell'applicativo? In caso di kill del processo? Rimarrebbe il blocco.
In applicazioni web è molto difficile gestire la chiusura del browser o della scheda di lavoro.

è lo stesso principio dei sistemi di versionamento, se blocchi la risorsa quando un utente ci sta lavorando nessuno può utilizzarla finchè non l'ha rilasciata

I sistemi di versionamento di questo tipo hanno portato una marea di problemi. Lock inspiegabili, lock di dipendenti dimessi etc...
L'ultimo che ancora può attivare questa opzione è TFS e bisogna richiederlo esplicitamente.
Il merge del codice, il gitflow etc... sono strumenti molto meno complessi da gestire per l'utente e il risultato è molto più soddisfacente.

Non sarebbe più opportuno invece avvisare l'utente che quel record è "bloccato" da un altro utente che lo sta variando PRIMA di entrare in variazione ? Attenzione, parlo di utente che entra in variazione e non in visualizzazione.

Questa funzionalità effettivamente manca ad Entity Framework così come a molti software moderni.
Però, se avessimo dei servizi di aggiornamento o di ricalcolo dati?
Se avessimo dei trigger che, partendo dall'inserimento in altre tabelle, vanno a modificare il nostro dato?
In questo caso non riusciremo più a modificare il dato. Stiamo parlando di un lock che blocca completamente in scrittura la riga.
Sono dell'idea che più spostiamo la nostra logica verso il database e meno riusciamo a scalare il nostro applicativo.
Non dico che il lock pessimistico sia da evitare, ma lo vedrei bene solo in particolarissimi casi perché introduce una marea di problematiche.
Piuttosto vedrei bene un pulsante per entrare in editing e notificare agli altri utenti che sono sulla schermata il blocco (applicativo). L'inibizione da parte dell'applicativo a volte è sufficiente.
Si sta cercando di minimizzare i tempi di transazione il più possibile, applicare un lock pessimistico al giorno d'oggi è una pratica che si cerca di non utilizzare.


si ci sono i cursori, ci sono i bloccaggi di pagine, cioè io leggo un rigo e lui mi blocca tutta la pagina con i righi adiacenti, ve lo immaginate ?

Questa affermazione non mi pare corretta. C'è il lock della singola riga. Questa non va bene per il caso?
SELECT ITEM_ID
FROM TABLE_ITEM
WITH(XLOCK, ROWLOCK)


Queste sono le mie opinioni personali. Non dico che sia da evitare il lock pessimistico, ma sia da applicare solo in particolarissimi casi.
24 messaggi dal 01 febbraio 2017
Il mio era un discorso molto semplificato, che metteva a paragone due DB, o modi di getsire un DB, quello che dovrebbe essere "lo stato dell'arte" e "quello che è stato".
Poi è chiaro che la scelta operativa sulla gestione delle concorrenze rimane in capo all'analista e può dipendere anche dall'ambito applicativo. Certamente le problematiche di un'applicazione (o servizio) WEB sono diverse da quelle in ambito Desktop, anche se oramai la differenza fra esse diventa sempre più sottile.

Ad esempio la soluzione al kill o crash del processo è semplcie, basta controllare l'utente e chiedergli se vuole sbloccare la precedente sessione .. tutto materiale già implemetato.

Infine un buon programmatore, sa risolvere già in fase di pianificazione del "kernel" dell'APP i problemi prima citati, con soluzioni operative che danno il giusto riconoscimento alla sua "creatività", perchè non dimentichiamo che alla fine chi progetta e scrive software è un ARTISTA del software che crea un'opera, al pari di un pittore.

Certo che è che gli strumenti in dotazione oggi cercano di ridimensionare tale ... ops è tardi, scappo, sennò ci perdiamo di casa ...

:-)

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.