Hello,

from what I gather, Tapestry intercepts requests and looks for the according 
page instances in the server-side application. The session id, if present, is 
transmitted with the request, so the appropriate page instance is used that 
maybe has some session-@Persist'ed members. Java code is executed which maybe 
changes the session-@Persist'ed members. Then the response takes the page 
instance, generates the appropriate HTML and sends the HTML response to the 
client.
So, the session id is probably stored somewhere in the HTML response or in a 
local cookie. Any session-@Persisted members are taken and used for generating 
the response, but only stored server-side.

The only bigger memory footprint are the possible multitude of server-side 
stored @Persist'ed members, if complex members are stored in the instances. 
Even then, if I use JPA.ENTITY as a strategy, the entities are probably not 
stored as entity instances, but only as their ID's. Then, the entities are 
queried for when page requests arrive.

Am I correct in how I describe this?

Regards,
Daniel P.

-----Ursprüngliche Nachricht-----
Von: Geoff Callender [mailto:geoff.callender.jumpst...@gmail.com] 
Gesendet: Mittwoch, 18. März 2015 09:31
An: Tapestry users
Betreff: Re: Memory Footprint in Tapestry

Here's a starting point for understanding @Persist:

        T5.4: 
http://jumpstart.doublenegative.com.au/jumpstart7/examples/state/storingdataina
        T5.3: 
http://jumpstart.doublenegative.com.au/jumpstart/examples/state/storingdatainapage

Geoff

On 18 Mar 2015, at 7:21 pm, Poggenpohl, Daniel 
<daniel.poggenp...@isst.fraunhofer.de> wrote:

> Hello,
> 
> I've yet to really understand which decisions for my Page and Component 
> classes regarding member variables lead to what amount of increase in memory 
> usage or bandwidth usage. Are there any documentation pages that I've maybe 
> overlooked?
> 
> For example, I have a page and database entities used in the page. What is 
> the difference in using @Persist for these entities? If I don't use @Persist, 
> are these objects only stored server-side in the VM?
> 
> If I use @Persist,
> - where is the data stored on the client side? In a cookie? Could I read this 
> data?
> - What does using SESSION lead to? Creating a session cookie?
> - should I rather persist primitive type (e.g. int) entity ID's in the page 
> or can I use the entities themselves?
> - Does JPA.ENTITY automatically store only the entity ID's in the cookie 
> between requests?
> 
> Should I rather use entity ID's or entities? If entities are used in multiple 
> methods, they always needed to loaded via DAO. After the first query the 
> objects probably are cached to speed up later ones, aren't they?
> 
> Regards,
> Daniel Poggenpohl
> --

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to