On Thu, 10 Jan 2013 18:39:26 -0200, Cezary Biernacki <cezary...@gmail.com>
wrote:
However they are not really created and discarded for every request,
just access private variables is changed in bytecode,
and content is stored outside class instances.
It is something that typical Java code does not do.
But, in Tapestry code, the fields, from our code perspective, still works
the same way as if they weren't changed at bytecode leve.
Another complication rises from mutable objects stored in a user session
(e.g. @Persist or @SessionState), as they might be accessed
simultaneously.
This is actually a general problem in Java webapps based directly or
indirectly in the Servlet API (or maybe even all or at least most webapps
in any language).
Personally, I would avoid any synchronization code in page/component
classes. It would mean that all static fields could hold only immutable
data.
If some mutable state would need to be shared between threads,
I would delegate synchronization handling either to services
or to mutable objects themselves.
Agreed. :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
