124 messaggi dal 08 settembre 2006
Buongiorno,
come da oggetto sto avendo a che fare con un'applicativo windows form installato su un server; tramite rdp un certo numero di utenti apre il programma, quindi eventualmente ci possono essere n istanze attive contemporaneamente;
da quanto so ogni istanza dovrebbe essere isolata rispetto alle altre, avendo in comune i dati presente nel/nei database utilizzati;
dato che non ho avuto a che fare molto spesso con applicazioni di questo tipo questo è del tutto vero? siamo sicuri che ogni istanza vive per conto suo? ci sono delle cautele da adottare nel codice? a parte ovviamente gestire le concorrenze sui dati?

inoltre questa applicazione ha la possibilità di aprile lo stesso form più volte creandone istanza multiple; in uno scenario del genere ci sono degli accorgimenti particolari da seguire? grazie
10.286 messaggi dal 09 febbraio 2002
Contributi
Ciao,
non so darti un'opinione precisa: dipende da come è stata scritta l'applicazione. Diciamo che il tuo scenario non è dissimile da un'applicazione web, in cui gli utenti accedono contemporaneamente alla stessa base dati (o a basi dati diverse).

La cosa che devi tenere in considerazione è che due utenti che accedono allo stesso database potrebbero sovrascriversi i dati a vicenda. Infatti, se entrambi aprono contemporaneamente e si mettono a modificare l'anagrafica di Mario, l'ultimo che salva sovrascriverà i dati dell'altro senza che ne abbiano notifica. Per evitare questo problema, come dicevi tu stesso, puoi implementare un meccanismo di concorrenza ottimistica.

Qui trovi descritto il problema e una sua possibile soluzione, che consiste nell'aggiungere una colonna Timestamp (o Version) alla tabella del db. Nel momento in cui dei dati vengono salvati, dovrai verificare che il valore della colonna non sia mutato e questa sarà la garanzia che nessun altro ha "toccato" i dati mentre si stava verificando la modifica da UI.
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/optimistic-concurrency

ciao,
Moreno

Enjoy learning and just keep making
24 messaggi dal 01 febbraio 2017
Sulla "concorrenza" ottimistica, apriamo un problema grosso quanto una casa, almeno per me che provengo da altri "ambienti".
Non sono mai riuscito a comprendere perchè un database come SQL Server che dovrebbe essere il punto di riferimento nel campo, non riesca a gestire (o anche segnalare) l'accesso in modifica di un record.
Uso da oltre 30 anni come DB, dei semplici file .DAT, ed il mio linguaggio gestisce perfettamente la concorrenza.

La soluzione segnalata (quella del timestamp) infatti ha un neo alla base.
Lato utente, io mi metto a modificare una mascherina con 2000 campi, e dopo quando salvo mi dici che non lo posso fare, in quanto i campi sono cambiati, o anche solo 1 campo. A quel punto l'unica scelta è di annullare le modifiche, per ricaricare il record aggiornato e tutto il lavoro che ho fatto ?

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.

Così, con un semplice file .DAT posso dire, "devo leggere il file" oppure "devo aggiornare il file" ed il resto della logica dei bloccaggi me la gestisce il compilatore del linguaggio .
E questo vale (per quel che può valere su un Forum di strumenti microsoft) sia che sono su UNIX, sia se mi trovo su un ICL, oppure su un IBM AS/400 o un IBM S/38 (giusto per andare un poco indietro nella memoria), o ancora su un DOS del 15/18' o anche su Windows a 16, 32 o 64 Bit eheheheh ....

Invece microsoft con tutta la sua tecnologia, ancora oggi mi obbliga ad inventare (e gestire a manina) i semafori ! ... 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 ?

Andiamo avanti, per tornare indietro !

Quindi per tornare al questito in calce, oltre al timestamp, ti consiglio di usare i semafori, e scriverti a manuzza tutto il codice di contorno; un pò più lungo, ma più funzionale per l'utente.

Poi se qualcuno mi svuole smentire, io sono in fase di apprendimento e "prendo".

Grazie.
10.286 messaggi dal 09 febbraio 2002
Contributi

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 ?

Quella che hai descritto si chiama concorrenza pessimistica ed è anche questa una strada percorribile. Personalmente preferisco quella ottimistica perché poi è facile confrontare il set di dati in possesso dell'utente con quello residente nel database e chiedere all'utente che cosa vuol fare (oppure fare il merge senza chiedergli niente, se non ci sono valori che conflittano). Vedi per esempio la gestione della concorrenza ottimistica con Entity Framework.
https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application



Invece microsoft con tutta la sua tecnologia, ancora oggi mi obbliga ad inventare (e gestire a manina) i semafori!
Andiamo avanti, per tornare indietro !

Oggi abbiamo gli strumenti per fare pure l'editing collaborativo in tempo reale. Sei sicuro che non sia tu ad ostinarti ad usare sempre gli stessi vecchi approcci?


io mi metto a modificare una mascherina con 2000 campi

Il problema principale qui è che non hai modellato correttamente la maschera ma hai buttato semplicemente dei controlli a schermo per semplificarti il lavoro. Stai riversando sull'utente un importante sovraccarico cognitivo che potresti evitargli realizzando delle Task Based UI.

Moreno

Enjoy learning and just keep making
24 messaggi dal 01 febbraio 2017
BrightSoul ha scritto:

Oggi abbiamo gli strumenti per fare pure l'editing collaborativo in tempo reale. Sei sicuro che non sia tu ad ostinarti ad usare sempre gli stessi vecchi approcci?

Sto abbandonando i vecchi strumenti, e mi sono registrato in questo Forum, perchè spero di imparare ad utilizzare i nuovi. Nessuna ostinazione. Quello che ho scritto, è il risultato delle mie ricerche, e diverse giornate a studiare la documentazione ufficiale microsoft (sempre molto dispersiva ed autoreferenziata).

Come ho detto se ci sono altre soluzioni, non ho nessun pregiudizio, io mi adeguo.
In questo senso dai post che leggo il tuo contributo è sempre molto importante ed "autorevole", e quindi apprezzato.


Il problema principale qui è che non hai modellato correttamente la maschera ma hai buttato semplicemente dei controlli a schermo per semplificarti il lavoro. Stai riversando sull'utente un importante sovraccarico cognitivo che potresti evitargli realizzando delle Task Based UI.
Moreno


Ho semplificato l'esempio, ad ogni modo mi sembra più logico (e funzionale) bloccare all'utente la variazione, con la sola possibilità di visualizzare i campi, piuttosto che permettere di variare il tutto e poi magari scoprire delle collisioni, in genere sono gli stessi campi che si correggono; la ragione sociale di un cliente o l'indirizzo, piuttosto che un prezzo di un articolo o la sua descrizione.

Ma siamo sempre lì, il DB non gestisce queste "collisioni".

Poi ripeto, io sono aperto ...
Non conosco Task Based UI, non so se magari l'ho realizzato incosciamente. Di cosa si tratta ?
Sto realizzando, anzi convertendo il mio "vecchio" applicativo in .NET e (ovviamente) non è una semplice conversione, ma una completa ristrutturazione, partendo da zero.
Se ci sono dei riferimenti o link, posta pure ... possibilmente in italiano, il mio inglese si è molto arruginito, sai ho una certa età .. eheheh ....

Grazie.

;-)
124 messaggi dal 08 settembre 2006
grazie della discussione molto interessante, alcuni aspetti già li conoscevo ma non era questo che mi interessava! per quanto riguarda la concorrenza sui dati ho già affrontato varie volte l'argomento e ci sono molteplici soluzioni; le mie perplessità invece sono sulla gestione degli oggetti form; potendo attivarne più di una copia dello stesso, dato che viene fatto il form.show e non il form.showmodal, volevo capire bene quali possono essere le implicazioni a livello di variabili, istanze di oggetti, ecc; volevo cioè essere sicuro che tutto quello che viene 'gestito' nell'istanza n della form1 sia isolato da quello dell'istanza n+1 della stessa form1; penso che sia già così e che non si debba fare nessuna gestione particolare ma volevo esserne sicuro, ad esempio se uso variabili esterne (definite in una classe a parte per esempio) per scambiare i dati fra una form chiamante e l'istanza aperta cosa può succedere se ci sono due istanze della stessa form?

grazie ancora
Modificato da bryger il 23 novembre 2017 14.49 -
10.286 messaggi dal 09 febbraio 2002
Contributi
Ogni volta che fai doppioclick sull'applicazione per aprirla, essa viene eseguita come un processo separato, che dispone di un proprio spazio di memoria, isolato da quello degli altri processi.
https://en.wikipedia.org/wiki/Process_isolation

Il fatto che vengano usati gli stessi eseguibili e le stesse librerie non rompe l'isolamento.
In generale, lo stato di un'istanza non influenzerà lo stato di un'altra istanza, almeno finché non vanno a collidere verso una risorsa comune (es. il database, il filesystem, il registro di windows, e così via).



Ho semplificato l'esempio, ad ogni modo mi sembra più logico (e funzionale) bloccare all'utente la variazione, con la sola possibilità di visualizzare i campi, piuttosto che permettere di variare il tutto e poi magari scoprire delle collisioni,

Usando la concorrenza ottimistica, il lavoro dell'utente non viene perso. Semplicemente, gli puoi notificare che un certo campo è cambiato e gli fai decidere se integrare i cambiamenti oppure scartarli.
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 -

Enjoy learning and just keep making
124 messaggi dal 08 settembre 2006
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.


Il fatto che vengano usati gli stessi eseguibili e le stesse librerie non rompe l'isolamento.
In generale, lo stato di un'istanza non influenzerà lo stato di un'altra istanza, almeno finché non vanno a collidere verso una risorsa comune (es. il database, il filesystem, il registro di windows, e così via).


si, in effetti ho fatto un po' di prove con istanze multiple di form ed oggetti e sembra che tutto sia isolato e corretto, ad esempio quando si distrugge la risorsa ho trovato il modo di 'sganciare' in modo specifico le risorse associate alla sola istanza corrente...

grazie

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.