You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Poggenpohl, Daniel" <Da...@isst.fraunhofer.de> on 2015/03/18 09:21:51 UTC
Memory Footprint in Tapestry
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
--
Dipl. Inf. Daniel Poggenpohl, Fraunhofer-Institut für Software- und Systemtechnik ISST
Compliance- und Sicherheitslösungen
Emil-Figge-Straße 91, 44227 Dortmund, Germany
Telefon: +49 (0) 231 / 9 76 77-323
mailto: Daniel.Poggenpohl@isst.fraunhofer.de<ma...@isst.fraunhofer.de>
http://www.isst.fraunhofer.de<http://www.isst.fraunhofer.de/>
AW: AW: Memory Footprint in Tapestry
Posted by "Poggenpohl, Daniel" <Da...@isst.fraunhofer.de>.
Hi,
some interesting and insightful information here. Thank you for that!
Regards,
Daniel P.
-----Ursprüngliche Nachricht-----
Von: Thiago H de Paula Figueiredo [mailto:thiagohp@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 <Da...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: AW: Memory Footprint in Tapestry
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 18 Mar 2015 07:32:43 -0300, Poggenpohl, Daniel
<Da...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: Memory Footprint in Tapestry
Posted by "Poggenpohl, Daniel" <Da...@isst.fraunhofer.de>.
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.jumpstart@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 <Da...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Memory Footprint in Tapestry
Posted by Geoff Callender <ge...@gmail.com>.
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 <Da...@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
> --
> Dipl. Inf. Daniel Poggenpohl, Fraunhofer-Institut für Software- und Systemtechnik ISST
> Compliance- und Sicherheitslösungen
> Emil-Figge-Straße 91, 44227 Dortmund, Germany
> Telefon: +49 (0) 231 / 9 76 77-323
> mailto: Daniel.Poggenpohl@isst.fraunhofer.de<ma...@isst.fraunhofer.de>
> http://www.isst.fraunhofer.de<http://www.isst.fraunhofer.de/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
AW: Memory Footprint in Tapestry
Posted by "Poggenpohl, Daniel" <Da...@isst.fraunhofer.de>.
Hi,
yes, I've read http://tapestry.apache.org/persistent-page-data.html. I just couldn't wrap my head around it before because I always thought storing data between requests automatically meant storing it in a client-side cookie or something like that. This has been cleared up, thank you for that.
JPA.ENTITY was a really stupid shorthand for JpaPersistenceConstants.ENTITY because I was too lazy at that moment, so sorry for that.
> This is up to the servlet container, not Tapestry.
Sometimes I feel that such things would be clear to me if I'd read some sort of Web Applications for Starters or something like that. I've dabbled in web development before, but somehow I've yet to find a good primer for the basics.
Anyone know a good book for web application/development?
>> - should I rather persist primitive type (e.g. int) entity ID's in the
>> page or can I use the entities themselves?
> It depends on the usage. If you just want to store just a reference to the object, not storing changes that
> weren't propagated to the database yet,
Something's missing there, I presume?
> Anyway, the recommended approach is to *not* use @Persist unless you've left with no other option. The
> best way to pass an entity reference from one page to another or to an event link is using the context, as
> explained here: http://tapestry.apache.org/page-navigation.html. This avoid usage of HttpSession, lowering the
> memory usage and avoiding problems when the user uses multiple tabs
I'll look into unpersisting most of my persisted page data then when given the time, then.
Regards,
Daniel P.
-----Ursprüngliche Nachricht-----
Von: Thiago H de Paula Figueiredo [mailto:thiagohp@gmail.com]
Gesendet: Mittwoch, 18. März 2015 13:49
An: Tapestry users
Betreff: Re: Memory Footprint in Tapestry
On Wed, 18 Mar 2015 05:21:51 -0300, Poggenpohl, Daniel <Da...@isst.fraunhofer.de> wrote:
> Hello,
Hi!
Have you seen http://tapestry.apache.org/persistent-page-data.html?
> 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?
Non-annotated fields are kept during the request and thrown away when it finishes. Where it's stored depends on the value attribute of @Persist for that given field. With @Persist(PersistenceConstants.SESSION), it's basically putting the field into the HttpSession with an attribute name crafted to be unique among pages and components, avoiding mix-ups. With @Persist(PersistenceConstants.CLIENT), it's stored on the client, as a query parameter or hidden field. With @Persist(PersistenceConstants.FLASH), it's stored in the session, but automatically removed after it's read in another request. This information was taken from here:
http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/PersistenceConstants.html.
If you're using tapestry-hibernate, you can use @Persist(HibernatePersistenceConstants.ENTITY). If you're using tapestry-jpa, you can use @Persist(JpaPersistenceConstants.ENTITY). These last two store just class name and id, not the entity object itself.
> If I use @Persist,
> - where is the data stored on the client side? In a cookie? Could I
> read this data?
See above.
> - What does using SESSION lead to? Creating a session cookie?
This is up to the servlet container, not Tapestry.
> - should I rather persist primitive type (e.g. int) entity ID's in the
> page or can I use the entities themselves?
It depends on the usage. If you just want to store just a reference to the object, not storing changes that weren't propagated to the database yet,
> - Does JPA.ENTITY automatically store only the entity ID's in the
> cookie between requests?
I'm not sure what you mean by JPA.ENTITY here. Anyway, Tapestry itself, out-of-the-box, doesn't use cookies to store @Persist'ed fields, but you can use Or use the ENTITY persistent field strategies explained above. In addition, you can also implement your own PersistentFieldStrategy to store @Persist'ed fields in any way you want: session, database, cookie, by id, whole object ...
> 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?
Tapestry itself doesn't cache your objects unless you explicitly ask. You can use the @Cached annotation in a page, component and mixin method and the method return value will be cached on first call in a given request, with subsequent method calls in the same request just returning the cached values.
Anyway, the recommended approach is to *not* use @Persist unless you've left with no other option. The best way to pass an entity reference from one page to another or to an event link is using the context, as explained
here: http://tapestry.apache.org/page-navigation.html. This avoid usage of HttpSession, lowering the memory usage and avoiding problems when the user uses multiple tabs.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Memory Footprint in Tapestry
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 18 Mar 2015 05:21:51 -0300, Poggenpohl, Daniel
<Da...@isst.fraunhofer.de> wrote:
> Hello,
Hi!
Have you seen http://tapestry.apache.org/persistent-page-data.html?
> 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?
Non-annotated fields are kept during the request and thrown away when it
finishes. Where it's stored depends on the value attribute of @Persist for
that given field. With @Persist(PersistenceConstants.SESSION), it's
basically putting the field into the HttpSession with an attribute name
crafted to be unique among pages and components, avoiding mix-ups. With
@Persist(PersistenceConstants.CLIENT), it's stored on the client, as a
query parameter or hidden field. With
@Persist(PersistenceConstants.FLASH), it's stored in the session, but
automatically removed after it's read in another request. This information
was taken from here:
http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/PersistenceConstants.html.
If you're using tapestry-hibernate, you can use
@Persist(HibernatePersistenceConstants.ENTITY). If you're using
tapestry-jpa, you can use @Persist(JpaPersistenceConstants.ENTITY). These
last two store just class name and id, not the entity object itself.
> If I use @Persist,
> - where is the data stored on the client side? In a cookie? Could I read
> this data?
See above.
> - What does using SESSION lead to? Creating a session cookie?
This is up to the servlet container, not Tapestry.
> - should I rather persist primitive type (e.g. int) entity ID's in the
> page or can I use the entities themselves?
It depends on the usage. If you just want to store just a reference to the
object, not storing changes that weren't propagated to the database yet,
> - Does JPA.ENTITY automatically store only the entity ID's in the cookie
> between requests?
I'm not sure what you mean by JPA.ENTITY here. Anyway, Tapestry itself,
out-of-the-box, doesn't use cookies to store @Persist'ed fields, but you
can use Or use the ENTITY persistent field strategies explained above. In
addition, you can also implement your own PersistentFieldStrategy to store
@Persist'ed fields in any way you want: session, database, cookie, by id,
whole object ...
> 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?
Tapestry itself doesn't cache your objects unless you explicitly ask. You
can use the @Cached annotation in a page, component and mixin method and
the method return value will be cached on first call in a given request,
with subsequent method calls in the same request just returning the cached
values.
Anyway, the recommended approach is to *not* use @Persist unless you've
left with no other option. The best way to pass an entity reference from
one page to another or to an event link is using the context, as explained
here: http://tapestry.apache.org/page-navigation.html. This avoid usage of
HttpSession, lowering the memory usage and avoiding problems when the user
uses multiple tabs.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org