Hi, some interesting and insightful information here. Thank you for that!
Regards, Daniel P. -----Ursprüngliche Nachricht----- Von: Thiago H de Paula Figueiredo [mailto:thiag...@gmail.com] Gesendet: Mittwoch, 18. März 2015 14:07 An: Tapestry users Betreff: Re: AW: Memory Footprint in Tapestry On Wed, 18 Mar 2015 07:32:43 -0300, Poggenpohl, Daniel <daniel.poggenp...@isst.fraunhofer.de> wrote: > Hello, Hi! > from what I gather, Tapestry intercepts requests and looks for the > according page instances in the server-side application. Correct, as Tapestry is implemented as a servlet filter, not a servlet, so "intercepting requests" is a valid statement IMHO. :) > The session id, if present, is transmitted with the request This is up to the servlet container. Tapestry just uses the HttpSession provided by Jetty, Tomcat, etc. > , so the appropriate page instance is used that maybe has some > session-@Persist'ed members. Not correct. @Persist'ed fields (methods aren't persisted) bytecode is actually changed by Tapestry so, when you're reading it, the actual code being executed is a method call. Same when you're writing to the field. You can take a look at the source of PersistWorker to see how this transformation is done. Since Tapestry 5.2, it doesn't even use a page pool anymore: each page class has exactly one instance and non-annotated fields are changed to method calls and the in-request state is delegated to a Map. But, of course, you don't need to worry about it at all: this is just opaque implementation details, so much that almost nothing changed to how your page classes behave when the page pool was removed. Almost because the @Retain annotation lost its meaning and use, as it was tied to the page pool, but that annotation was barely used anyway. > So, the session id is probably stored somewhere in the HTML response > or in a local cookie. That's up to the servlet container, the one which actually implements HttpSession, which is used by Tapestry as a black box, not caring how it's implemented. > Any session-@Persisted members are taken and used for generating the > response, but only stored server-side. It depends on @Persist strategy, the default being storing in the HttpSession, but there's also client storage too. > 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. This paragraph is correct. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
