Impostare un progetto

[texerasmo]

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]

Io sono contro l'ingegnere a prescindere

[71104]

progetto di che?
quali sessioni? quali request?
mi ritrovo leggermente senza contesto

di' la verità, quel post l'ha scritto l'ingegnere

[^TiGeRShArK^]

Originariamente inviato da 71104

progetto di che?
quali sessioni? quali request?
mi ritrovo leggermente senza contesto

di' la verità, quel post l'ha scritto l'ingegnere

sicuramente è qualche webapp così ad occhio

[cionci]

Seeee...una web app senza sessioni ? E perché mai ?

[texerasmo]

Si parliamo di una web-app

Ing,per motivi di prestazioni.

[cionci]

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

[danx85]

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]

Quindi danx85 cosa vorresti dirci?

[isAlreadyInUse]

Che ha scoperto il copia/incolla

[fek]

Originariamente inviato da texerasmo

Si parliamo di una web-app

Ing,per motivi di prestazioni.

Ha misurato in qualche modo la differenza di prestazioni nel vostro scenario?

[danx85]

Originariamente inviato da isAlreadyInUse

Che ha scoperto il copia/incolla

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]

Pensa che mi voglio per forza a "Zelig"... che faccio vado?

[texerasmo]

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.

[cionci]

Originariamente inviato da danx85

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...

[danx85]

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?

[cionci]

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

[danx85]

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]

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]

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