Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Test ride Can-Am Origin: la moto elettrica che fa dimenticare il motore a scoppio (ma occhio all'autonomia)
Test ride Can-Am Origin: la moto elettrica che fa dimenticare il motore a scoppio (ma occhio all'autonomia)
Abbiamo provato per una settimana intera la Can-Am Origin, la Dual Sport elettrica del gruppo canadese BRP: ecco com'è andata tra città, autostrada e un primo assaggio di sterrato
Logitech G325, G305 e G316 X: il tris per chi non vuole rinunciare a nulla, spendendo poco
Logitech G325, G305 e G316 X: il tris per chi non vuole rinunciare a nulla, spendendo poco
Nelle ultime settimane abbiamo provato il mouse Logitech G305, la tastiera G316 X 98 e le cuffie G325. Si tratta del setup entry-level di Logitech che ormai, di "entry-level" ha ben poco. Tastiera e mouse offrono prestazioni di livello competitivo con quasi nessuna rinuncia e un livello di personalizzazione estremamente elevato. Le cuffie, invece, hanno mostrato qualche debolezza, ma propongono un ventaglio di funzionalità completo che consente di abbandonare completamente i cavi
Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio
Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio
POCO F9 Pro arriva sul mercato con l'obiettivo di portare prestazioni da smartphone top di gamma in una fascia di prezzo "più aggressiva", senza rinunciare a un comparto fotografico finalmente all'altezza. Dopo averlo testato sul campo, emerge uno smartphone molto più completo rispetto alla generazione precedente, ma anche con alcuni piccoli compromessi che diventano difficili da ignorare quando il prezzo di listino sfiora i 1.000 euro.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 17-02-2007, 11:29   #1
Unrue
Senior Member
 
L'Avatar di Unrue
 
Iscritto dal: Nov 2002
Messaggi: 7417
(Java) Domande varie su JSP e Servlet

Salve, avrei alcune domande su tali argomenti.

1) In molte guide JSP fanno un esempio in cui c'è una pagina JSp che prende in ingresso dati da un form. Tale pagina poi richiama una Servlet a cui passa i dati immessi. Ma io non capisco, una pagina JSP non diventa automanticamente una Servlet? Che bisogno c'è che la pagina JSP richiami un'altra Servlet?

2) Ho visto che in alcuni casi Vi è una implementazione di thread all'interno delle servlet. Ora, io so che la gestione della concorrenza tra servlet, a parte alcuni piccoli accorgimenti è a carico del Web Container, ad esempio Tomcat, e che ogni connessione a tale servlet è in pratica una specie di thread a se. Quindi, perchè implementare un ulteriore thread all'interno della Servlet? Grazie.
Unrue è offline   Rispondi citando il messaggio o parte di esso
Old 17-02-2007, 20:24   #2
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Per la uno, è certamente corretto dire che non c'è un'esigenza meccanica di divisione dei compiti. E' possibile tuttavia che l'autore abbia fatto una scelta strutturale. Non è insolito che un programma sia costruito come un insieme di parti ognuna responsabile di uno specifico gruppo di azioni. Probabilmente l'autore di quell'esempio ha inteso delegare ad un componente l'acquisizione dei dati ed ad un altro componente la sua manipolazione. Per farlo ha sfruttato la modularità che esiste nei linguaggi di programmazione ormai da tempo immemore.

Per la due è un problema di garanzie minime. Il server ha la responsabilità di gestire la fornitura del servizio rappresentato dalla servlet. Può usare un Thread solo per tutti, può usare un Thread per ogni connessione, può usare un pool di Thread e distribuire il carico tra di essi. Dal punto di vista della distribuzione del carico di lavoro tutto quello che il programmatore sa è che... non sa. La domanda che si fa è: posso delegare al Thread che fornisce il servizio un compito che lo terrà impegnato per un bel po? Sapendo che ogni connessione è gestita da un Thread ad hoc la risposta sarebbe sì. Ma poichè non si può contare su questo comportamento la soluzione da preferire è "garantista": non sovraccarico un Thread di cui non conosco le responsabilità ma ne creo e controllo uno ad hoc. Nascono problemi anche in questo caso ma sono problemi che derivano interamente da presupposti noti e controllabili dal programmatore della servlet.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
Old 18-02-2007, 10:15   #3
loris_p
Senior Member
 
L'Avatar di loris_p
 
Iscritto dal: Aug 2006
Messaggi: 365
Quote:
1) In molte guide JSP fanno un esempio in cui c'è una pagina JSp che prende in ingresso dati da un form. Tale pagina poi richiama una Servlet a cui passa i dati immessi. Ma io non capisco, una pagina JSP non diventa automanticamente una Servlet? Che bisogno c'è che la pagina JSP richiami un'altra Servlet?
http://en.wikipedia.org/wiki/Model-v..._.28Java_EE.29
loris_p è offline   Rispondi citando il messaggio o parte di esso
Old 21-02-2007, 22:20   #4
Unrue
Senior Member
 
L'Avatar di Unrue
 
Iscritto dal: Nov 2002
Messaggi: 7417
Quote:
Originariamente inviato da PGI-Bis Guarda i messaggi
Per la uno, è certamente corretto dire che non c'è un'esigenza meccanica di divisione dei compiti. E' possibile tuttavia che l'autore abbia fatto una scelta strutturale. Non è insolito che un programma sia costruito come un insieme di parti ognuna responsabile di uno specifico gruppo di azioni. Probabilmente l'autore di quell'esempio ha inteso delegare ad un componente l'acquisizione dei dati ed ad un altro componente la sua manipolazione. Per farlo ha sfruttato la modularità che esiste nei linguaggi di programmazione ormai da tempo immemore.

Per la due è un problema di garanzie minime. Il server ha la responsabilità di gestire la fornitura del servizio rappresentato dalla servlet. Può usare un Thread solo per tutti, può usare un Thread per ogni connessione, può usare un pool di Thread e distribuire il carico tra di essi. Dal punto di vista della distribuzione del carico di lavoro tutto quello che il programmatore sa è che... non sa. La domanda che si fa è: posso delegare al Thread che fornisce il servizio un compito che lo terrà impegnato per un bel po? Sapendo che ogni connessione è gestita da un Thread ad hoc la risposta sarebbe sì. Ma poichè non si può contare su questo comportamento la soluzione da preferire è "garantista": non sovraccarico un Thread di cui non conosco le responsabilità ma ne creo e controllo uno ad hoc. Nascono problemi anche in questo caso ma sono problemi che derivano interamente da presupposti noti e controllabili dal programmatore della servlet.
Grazie della risposta, però avrei un'altra domanda. supponendo di aver creato un thread all'interno della servlet, tale thread lo controllo io. Ma quindi volendo posso creare più thread controllati da me dallo stesso thread creato dalla servlet? Si creerebbe un thread master della servlet e altri thread figli creati dal client. E' uno scenario possibile?
Unrue è offline   Rispondi citando il messaggio o parte di esso
Old 22-02-2007, 12:38   #5
PGI-Bis
Senior Member
 
L'Avatar di PGI-Bis
 
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
Se intendo correttamente il senso della domanda sì, è possibile. La precisazione è dovuta al fatto che in Java non c'è una relazione master-slave tra Thread. C'è invece una relazione parent-child tra ThreadGroup (ogni Thread appartiene ad un ThreadGroup). Occorre inoltre tenere conto del fatto che avere un riferimento ad un Thread Java non significa poterlo controllare: per farlo occorre che il Thread appartenga ad una più ampia struttura di controllo. Comunque è un sì: Java non cessa di essere un linguaggio concorrente quando vede due 'E' di fila .
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me!
PGI-Bis è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Test ride Can-Am Origin: la moto elettrica che fa dimenticare il motore a scoppio (ma occhio all'autonomia) Test ride Can-Am Origin: la moto elettrica che f...
Logitech G325, G305 e G316 X: il tris per chi non vuole rinunciare a nulla, spendendo poco Logitech G325, G305 e G316 X: il tris per chi no...
Recensione POCO F9 pro: potenza da vero top di gamma, display da 185 Hz e finalmente una fotocamera da prendere sul serio Recensione POCO F9 pro: potenza da vero top di g...
Tra audio e AI: la ricetta di Qualcomm per l'agentic AI Tra audio e AI: la ricetta di Qualcomm per l'age...
Qualcomm annuncia la nuova generazione di SoC Snapdragon 8 Elite Gen 6 Qualcomm annuncia la nuova generazione di SoC Sn...
Carburanti, dopo Eni anche IP annuncia u...
HEO Space ha rilasciato una nuova immagi...
La missione Artemis III sarebbe in ritar...
Apple apre Music Hall, una sala concerto...
Adobe arriva su Gemini e Claude: nuove f...
Non solo Fideuram: quasi 2 milioni di it...
I lettori CD di fascia alta potrebbero s...
Tutto il meglio di Amazon weekend: 5 nov...
Proscenic P15+ a 113€ su Amazon: scopa e...
TP-Link Wi-Fi 6 a 59,99€ e Tenda 4G03 Pr...
Un quasi top di gamma a 461€: lo smartph...
Roborock Saros 20 Neo e Flow Complete: 3...
Mac mini si trasforma: chip a 2 nanometr...
Su Amazon c'è un super TV Samsung...
La Cina ha rilasciato un satellite dallo...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 01:12.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v