Quote:
Originariamente inviato da Sgurbat
No, non credo intendesse lato WS ma lato client ovvero all'interno dell'applicazione che pesca i profili (record) e poi utilizza lo Stub per chiamare il WS.
Es:
-Applicazione client
- select N profili from table (es: 5)
- ciclo sui 5 profili presi
- apro 1 thread per ciascuno di essi
- all'interno del thread utilizzo lo Stub per chiamare il WS.
Ma la mia, al momento è solo un'ipotesi, oggi dovrei chiarire meglio.
Il WS è comunque nostro quindi eventuali modifiche si posso sempre fare ma, ripeto, credo che intendesse come quanto riportato sopra.
|
Ok, non avevo capito.
Allora il WS già acetta e processa richieste multiple; è il client che ne spedisce una e attende la risposta in modo sincrono, quando invece potrebbe spedirne varie contemporaneamente. Che è quello che dovrete fare.
Quindi invece di essere:
Quote:
select su db
result set di 5 record
invio record 1 al WS
attesa...
processo la risposta
invio record N al WS
attesa...
processo la risposta
invio record 5 al WS
attesa...
processo la risposta
termino
|
Sarà:
Quote:
select su db
result set di 5 record
thread1: invio record 1 al WS
thread2: invio record 2 al WS
thread3: invio record 3 al WS
thread4: invio record 4 al WS
thread5: invio record 5 al WS
attesa... [in teoria solo 30 sec. circa, se il WS processa più richieste in parallelo]
thread1: processo risposta 1
thread2: processo risposta 2
thread3: processo risposta 3
thread4: processo risposta 4
thread5: processo risposta 5
termino
|
Ma quindi i tuoi dubbi circa i benefici dell'usare più thread in questo scenario quali sono? No perchè, chiarendo i miei dubbi ti sei praticamente risposto da solo
