iBaffiPro ha scritto:
Ho timore di commettere qualche errore nella scrittura dei dati nel database.
Il metodo seguente funziona e viaggia circa 4 volte più veloce del ciclo for.
Allora:
1) Io ti ho mostrato il "mio" ForkJoinListMutator come strumento per modificare "in loco" una lista in maniera parallelizzabile. Ma in generale il Fork-Join pool NON è stato pensato e fatto per fare operazioni di I/O o su DB. Insomma, dovrebbe essere usato
solo per computazioni "pure", non per cose potenzialmente lunghe/bloccanti.
Se vuoi davvero fare query su DB in maniera parallelizzabile, allora dovresti usare un thread pool "normale", quello a cui si sottomettono dei "task" (Runnable/Callable). Non il Fork-Join.
Nel tuo caso comunque il concetto di modifica della lista ha pure poco senso, perché si presuppone che il getNome() dia lo stesso nome (magari solo come oggetto diverso, distinto) uguale al nome passato a registrazione(
n, .....). Quindi cosa cambia nella lista?? Concettualmente nulla ....
2) Ti stai fissando sul fatto di pensare che se hai solo 4 core puoi avere solo 4 scritture in parallelo su db, cioè un parallelismo uguale al numero dei core. Sbagliato!! Quando hai un "lavoro" da rendere parallelizzabile, devi avere ben chiaro se si tratta di un lavoro che usa molto la cpu o usa molto il I/O (si intende I/O su file ma anche networking o accesso a DB).
Fare es. un reverse su una stringa (non grossa) può richiedere
microsecondi (anche meno ...), fare una query su DB può richiedere
millisecondi. Stiamo parlando di un rapporto 1:1000.
Se il tuo lavoro fa quasi esclusivamente query su db, il problema non è il processore ... ma le Connection al DB.
Ora, io non so se/come hai configurato il connection-pool. In Spring Boot il HikariCP se non sbaglio (e se non hanno cambiato di recente) usa per default un
max di 10 Connection al DB.
Se hai max 10 Connection, è
inutile avere un mega processore con 32 core. Anche creando 32 thread (idealmente, uno per core), la maggior parte dei thread starebbe lì fermo in sospensione, in attesa di ottenere una Connection libera. Questo non è "scalare" in prestazioni.
Lo dico in altro modo: se i tuoi lavori da parallelizzare fanno quasi esclusivamente query su DB,
il "collo di bottiglia" NON è il numero dei core ... ma delle Connection!!
iBaffiPro ha scritto:
In sostanza creo una lista di String con N nomi utente differenti e li registro a database con registrazione(). Se nel metodo registrazione() metto 2 query, una per scrivere il dato e l'altro per recuperarlo ottengo questo errore:
org.springframework.dao.EmptyResultDataAccessException: Incorrect result size: expected 1, actual 0
Perché la query per cercare il dato manda in tilt il sistema?
Senza vedere bene cosa c'è "sotto" quel
private Utente registrazione(String nomeIscritto, String passwordIscritto){
(in particolare COSA fanno eseguiRegistrazione.registrazione() e utenteRepository.trovaUtente() )
è parecchio difficile da dire.
iBaffiPro ha scritto:
Nel caso la mia app fosse pubblicata e N utenti si registrassero in contemporanea la procedura di registrazione gestita da Tomcat avverrebbe in parallelo oppure no?
Ciascuna richiesta HTTP viene "servita" da un thread a sé stante, quindi dipendentemente da come è configurato il web server, sì, le richieste possono essere molto in parallelo (anche centinaia).
iBaffiPro ha scritto:
Appena finito questa esercitazione mi prendo un bel manuale di java
Anche due .... o tre ..... su ambiti più specialistici .....
iBaffiPro ha scritto:
perché mi mancano molte cose
Sì moooooolte, purtroppo. Se non migliori un po' le conoscenze, temo che continuerai a scrivere codice per niente buono e per niente ottimale come prestazioni.