I don't think that you can blindly apply to general Java logic to code in page and component classes. They are rewritten by Tapestry, and normal rules don't fully apply.
On surface page and components behave as they would be created and discarded for every request, so you normally don't need to worry about synchronizing access to private variables (but still there are some special cases). 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. Another complication rises from mutable objects stored in a user session (e.g. @Persist or @SessionState), as they might be accessed simultaneously. 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. Best regards, Cezary On Thu, Jan 10, 2013 at 8:07 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 10 Jan 2013 16:37:14 -0200, bhorvat <horvat.z.bo...@gmail.com> > wrote: > > Interesting. >> >> And what would be best approach for the multiple threads accessing the >> same >> even handler? >> >> >> Synchronized key word, synchronized block, using Lock or Barrier or >> something else? >> > > If your event handler method uses only parameters, its own variables and > non-static fields, you don't need any kind of synchronization. Otherwise, > this question becomes off-topic, being a general Java question and not > something related to Tapestry. > > -- > Thiago H. de Paula Figueiredo > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apache.org> > For additional commands, e-mail: users-h...@tapestry.apache.org > >
