View Full Version : Impostare un progetto
texerasmo
15-11-2007, 17:31
Salve a tutti,
è nato un diverbio tra me e un collega su come impostare un progetto
Lui dice (ing.) che non bisogna mai utilizzare le session io affermo il contrario.
Be è logico come tutti state pensando in questo momento dipende da quello che dovresti fare.
lui(ing) basa il principio che se devo fare un passaggio 3-4 pagine conviene usare una request, tenendo presente che in un progetto di medie dimensioni degli oggetti possono essere riutilizzati.
Quindi io per prima cosa farei una initApplication con un serie di oggetti che posso essermi utili.
Poi utilizzarei delle session temporanee
voi che ne pensate?
isAlreadyInUse
15-11-2007, 17:32
Io sono contro l'ingegnere a prescindere :asd:
progetto di che? :wtf:
quali sessioni? quali request?
mi ritrovo leggermente senza contesto :mbe:
di' la verità, quel post l'ha scritto l'ingegnere :asd:
^TiGeRShArK^
15-11-2007, 19:32
progetto di che? :wtf:
quali sessioni? quali request?
mi ritrovo leggermente senza contesto :mbe:
di' la verità, quel post l'ha scritto l'ingegnere :asd:
sicuramente è qualche webapp così ad occhio :p
Seeee...una web app senza sessioni ? E perché mai ?
texerasmo
16-11-2007, 09:35
Si parliamo di una web-app
Ing,per motivi di prestazioni.
Assolutamente no...non c'è alcuna differenza di prestazioni.
Quando si lavora sulle sessioni i dati vengono scritti su un file (almeno in php) e questo file ovviamente risente di tutti i livelli di caching del sistema. In pratica con buona percentuale le prestazioni relative alla lettura/scrittura del file di sessione sono simili a quelle della lettura scrittura in memoria ;) L'unico costo è il context switching per eseguire l'api di sistema che accede al file.
Non so come funzionano le varie implementazioni, ma questo costo è eliminabile con un livello di caching interno alle api per l'accesso alla sessione ;)
Request scope
Information in this scope is created some time after the request is received and is disposed of some time after the response is complete. It is a good practice to have the backing beans for pages be in the request scope where possible, and maintain separate beans that store only the information that will not need to be continually passed between the client and server.
The following types of information are good candidates for storing in the request scope:
* Value bindings (e.g. <h:inputText value="#{MyBean.lastName}" /> should always be stored in request scope since they are automatically restored on every request.
* Component bindings (e.g. <h:inputText binding="#{MyBean.lastNameComponent}" />) should always be stored in request scope since their value is no longer valid after a request has been processed anyway. The component tree is reconstituted during each incoming request, changing the physical instances these component bindings will point to.
* References to database resources such as connections, statements, and result sets should be properly closed and discarded before a request is complete (see the section on resource management below for details).
* Caches of database query results - see section on caching database query results for details.
* Temporary results of calculations used for rendering the current view.
Session scope
Information in this scope is created some time after the current user's first request is received and is disposed of after a configurable period of inactivity (i.e. when a request has not been received in a certain period of time), or when a session is explicitly invalidated by the application. It is also disposed of when the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.
The following types of information are good candidates for storing in the session scope:
* Navigational context, for example the album the user is currently editing in a music catalog application. This type of information could potentially be carefully passed back and forth via hidden input fields, but this is error prone and can be difficult to manage together with form validation and when forms are shared between different parts of an application.
* Information that is specific to this session, but temporary, such as short-lived shopping carts. The information can be made persistent by also updating a database table. The recommended way to do this is via entity EJBs, but this can be done by manually coding database-aware JavaBeans as well.
* Security sensitive information that should not be continuously sent back and forth between the client and server.
* Caches of database query results - see section on caching database query results for details.
Application scope
Information in this scope is created some time after the application is deployed and is discarded some time before the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.
The following types of information are good candidates for storing in the application scope:
* Information that transcends particular users or sessions, such as application settings.
* Caches of database query results - see section on caching database query results for detai
texerasmo
16-11-2007, 11:14
Quindi danx85 cosa vorresti dirci?
isAlreadyInUse
16-11-2007, 11:15
Che ha scoperto il copia/incolla :asd:
Si parliamo di una web-app
Ing,per motivi di prestazioni.
Ha misurato in qualche modo la differenza di prestazioni nel vostro scenario?
Che ha scoperto il copia/incolla :asd:
Umorismo esplosivo direi.
Ad ogni modo, si cerca di capire solamente se la Session ha delle ripercussioni sulle prestazioni del server.
Come ha detto cionci, i dati della session vengono memorizzati su file anche se, a suo tempo, ho imparato che i parametri in session venivano allocati nell' Heap. Sto confondendo qualcosa forse? Ci sono delle fonti attendibili dove potersi informare con più precisione?
isAlreadyInUse
16-11-2007, 12:03
Pensa che mi voglio per forza a "Zelig"... che faccio vado?
texerasmo
16-11-2007, 12:39
Non sono uno esperto cmq credo che se noi pensiamo a come agiscono i framework da Hibernate(DB) a Struts(Web-Application) possiamo fare rifertoimento da li.
Credo che le prestazioni sul server non ci siano, oggi sono pontenti e molto meno costosi.
Poi non dobbiamo sottolineare aspetto del lavoro del programmatore.
(almeno chè ing. non piace ricevere fatture :) (scherzo) ).
Poi ci sono le var di sessioni temporanee in java e in ambiente microsoft esistono non so in php.
Cmq l'ambiente è in java.
Come ha detto cionci, i dati della session vengono memorizzati su file
In php vengono memorizzate su file...si possono anche vedere ;)
Poi in JSP non ne ho idea...ci sta che vengano memorizzate direttamente in memoria ed in tal caso ci sono ancora meno possibilità che creino problemi al server...
Però, correggimi se sbaglio, se memorizzi su file puoi contare su hardisk capienti dei giorni d'oggi (non costa molto anche un hardisk da 80GB), cosa invece diversa se parliamo di memoria.
Se hai molti utenti che occupano lo heap con delle sessioni (in mancanza di hardware) converrebbe strutturare l'applicazione con meno dati permanenti. No?
Fai 4000 utenti nell'arco di 15 minuti della durata tipica della sessione...a dire tanto 20KB per utente...sono 80 MB che stanno tranquillamente in qualsiasi ram di un server. Ed in ogni caso sono stime pessimistiche che possono essere vantate da pochi server nel mondo ;)
Grazie alla mia nuova tecnica ora ti incollo quello che ho trovato:
For in-memory user session storage, the default 256 MB WebSphere(R) Java(TM) heap supports about 3,300 user sessions.
Quindi sui 256MB per 3mila e passa sessioni, secondo questa fonte.
Però non è inesatta come affermazione? Una sessione può contenere pochi o molti dati, ad ogni modo, se siamo sicuri (SICURI) che per tenere memorizzati anche un bel po' di dati per utente servono anche solo manciate di KB, possiamo anche abusare di Session... c'è solo da verificare il punto precedente.
texerasmo
16-11-2007, 16:10
Allora quello che hai scritto fa riferimento a WebSphere quindi il valore potrebbe cambiare con OAS JBOSS BEA JETTY TOMCAT ecc....
Quindi ragiona prima di utilizzare la tua "tecnica ".
Credo che quando si imposti un proggetto si deve stabilire un scaletta di valori.
A) SICUREZZA
B) PERFORMANCE
C)GESTIONE DEL PROGETTO
certo i punti a e b posso anche capovolgersi in certi casi.
texerasmo
16-11-2007, 16:15
ho dimenticato questo
Integer (intero) 2 byte
Long (intero lungo) 4 byte
Single (precisione semplice, virgola mobile) 4 byte
Double (precisione doppia, vigola mobile) 8 byte
String (stringa) 1 byte per carattere
Byte 1 byte
Boolean 2 byte
Date 8 byte
puoi farti dei calcoli se vuoi
Allora quello che hai scritto fa riferimento a WebSphere quindi il valore potrebbe cambiare con OAS JBOSS BEA JETTY TOMCAT ecc....
Non ti ho capito, puoi spiegarti meglio? Rimane il fatto che non capisco perchè dovrebbero esserci dei valori precisi per le sessioni.
Quindi ragiona prima di utilizzare la tua "tecnica ".
Io almeno sapevo cos'era lo Heap :doh:
texerasmo
16-11-2007, 16:36
Sai cosa sono quelli che ho scritto?
Tomcat è un web container, Jboss anche EJB container, gli altri non li conosco.
La domanda rimane la stessa, perchè per 3,300 sessioni vengono occupati 256MB? Non dipende solo da quando sono riempite queste session?
Edito, mi era sfuggito quell' <About>. Di conseguenza, credo sia accertato che anche per grandi quantità di dati lo spazio allocato nello Heap rimane sostanzialmente poco.
texerasmo
16-11-2007, 16:54
Quello che tu hai trovato potrebbe essere un calcolo fatto utilizzando WebSphere quinndi questo significa che con un altro Application server i valori potrebbero cambiare in meglio o in peggio.
Per mettere fine a questa discussione io dire che
Request
sono quelle che devono essere valide solo una richiesta,
quindi per andare nell'altra pagina
La session
la session si usa per le variabili che vuoi che valgono per tutta la sessione "Navigazione"
Quindi non è pensabile che per un Navigazione si usi la request o si sia a favore della request.
blackknight
16-11-2007, 16:56
In java le session sono immagazzinate in memoria...
erasmo per il tuo problema dipende dal contesto...cmq conviene usare le sessioni per avere oggetti riusabili e maggiori performance.
blackknight
16-11-2007, 16:57
Tomcat è un web container, Jboss anche EJB container, gli altri non li conosco.
La domanda rimane la stessa, perchè per 3,300 sessioni vengono occupati 256MB? Non dipende solo da quando sono riempite queste session?
Edito, mi era sfuggito quell' <About>. Di conseguenza, credo sia accertato che anche per grandi quantità di dati lo spazio allocato nello Heap rimane sostanzialmente poco.
Penso sia un calcolo empirico...diciamo una media:D
Penso sia un calcolo empirico...diciamo una media:D
Essì. Grazie a tutti per le informazioni.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.