Blocca i thread o non blocca i thread?

Question

Blocca i thread o non blocca i thread?

#1 da (0 voti)
#2 da (0 voti)

-1

Ho un'applicazione (full-stack) che viene utilizzata milioni di volte contemporaneamente.

Alcune proprietà vitali dell'applicazione sono gestite dal lato client (al momento sembrava il metodo più semplice per me), ma naturalmente questo ha problemi di sicurezza, quindi devo gestire tutte le proprietà sul lato server.

Stavo pensando di aggiungere tutte queste proprietà a una classe helper che ho che è public static . Poiché il client gestiva alcune di queste proprietà, non dovevo preoccuparmi se queste proprietà fossero o meno quelle giuste poiché erano per cliente. Se sono sul lato server non sono più sicuro di come sia certo che il server stia utilizzando le proprietà corrette per il client X.

Come posso assicurarmi che vengano utilizzate le proprietà corrette?

Tuttavia, mettere queste proprietà sulla classe helper causerebbe conflitti, no? Poiché molti clienti possono accedere alla stessa proprietà. Questo sarebbe male.

Le proprietà in questione servono per identificare i parametri dell'applicazione. cioè l'applicazione per le foto? L'applicazione per i dati personali è? È l'applicazione per il mio carrello? Può essere utilizzato in molte parti del sito Web, quindi ho bisogno di sapere quale parte può funzionare correttamente. Se sono in foto, ma penso che sia nei dati personali, questo è un problema.

Non gestisco l'autenticazione dei client; è una libreria che lo fa, quindi non è un problema.

concurrency multithreading

posta Joze 31.03.2016 - 10:10

fonte

2 risposte

Leggi altre domande sui tag concurrency multithreading

Winform User Control su ASP? colonna di monitoraggio (offset) in presenza di caratteri di tabulazione

score 0 · Answer 1

Penso che devi stare indietro e considerare dove vuoi persistere le proprietà. Il posto ovvio è in una tabella del database indicizzata su clientID. Il modo in cui si mappano queste proprietà in classi è un problema risolto a lungo dai framework ORM (ad esempio MyBatis e Hibernate nello spazio Java). È altamente improbabile che le tue proprietà finiscano come variabili statiche.

Per quanto riguarda il threading, è necessario bloccare l'accesso a qualsiasi struttura dati a cui si accede da più thread contemporaneamente, in cui uno o più thread possono modificare la struttura. Ad esempio:

Se queste proprietà vengono impostate da SQL quando viene aggiunto un nuovo cliente, sono effettivamente di sola lettura e non è necessario alcun blocco.
Se il client può modificare queste proprietà e consentire più accessi simultanei dallo stesso client, è necessario un blocco affidabile.
Allo stesso modo se un amministratore di sistema può modificare le proprietà mentre il client è loggato, allora il blocco è nuovamente richiesto.

score 0 · Answer 2

Devi identificare ciascun client - questo potrebbe essere l'indirizzo IP o un ID di sessione passato in ogni chiamata o un token autenticato.

Si memorizzano le proprietà in memoria o in un archivio persistente come un database. È necessario cercare le proprietà su ogni richiesta dall'identificazione passata.

Quindi, tutto è semplice e buono dato che ora disponi di una raccolta di proprietà modificate dagli utenti. Se è necessario bloccare questa raccolta dipende dall'accesso simultaneo alla raccolta stessa e al tipo di raccolta. È necessario bloccare l'accesso alla raccolta, poiché non si desidera eseguirne la ricerca per trovare le proprietà di un utente se un altro thread sta rimuovendo la proprietà di un utente. Quindi è necessario bloccare tutte le letture e le scritture (è possibile utilizzare un blocco di lettura / scrittura più specializzato ma iniziare con una semplice sezione critica all'inizio)

Se le proprietà che sono memorizzate non dipendono dalla collezione, ad esempio sono in una mappa o dizionario o simili, quindi una volta trovate le proprietà è possibile restituire loro un riferimento per il resto della richiesta senza ulteriore blocco . cioè si blocca solo per trovare le proprietà. Se la tua raccolta potrebbe cambiare il riferimento alle proprietà (ad esempio aggiungendo una nuova voce prima di quella che hai un riferimento per modificare la voce di riferimento) dovrai prima crearne una copia prima di rilasciare il blocco.

So che questa è tutta una risposta "dipende", ma in generale per una risorsa condivisa tra accessi concorrenti, è necessario bloccare quella risorsa quando viene letta o scritta. Per una raccolta, ciò significa bloccare la raccolta quando aggiungi, rimuovi o leggi una voce da essa.