In our application, many ajax requests are processed in the same
session, sometimes causing conflicts when they update shared session
information. I found synchronizing the logic within my event handlers to
be useless since many components access shared objects from property
bindings within
Thanks josh and howard,
After my initial realisation it all makes more sense now.
p.
On 27/12/2011 9:25 AM, Howard Lewis Ship wrote:
For example, rather than directly creating and manipulating an entity
object inside a page or component event handler method, you might move
the logic into a
Tapestry also shields you from the multi-threaded aspects of web
application development...
unless you're dealing with concurrent requests to objects in a users
session. When you're dealing with shared resources, protecting them
from concurrent access is in the developers hands.
I had assumed
For example, rather than directly creating and manipulating an entity
object inside a page or component event handler method, you might move
the logic into a service, which you can ensure is a singleton, making
it much simple to ensure the threadsafe behavior of the logic.
On Mon, Dec 26, 2011
Hi all,
I found a nasty situation where some xhr requests were running into
nullpointers on properties of persistent page properties/fields. My
theory being that there is some access to fields of a persistent field
in XHR request A, while XHR request B is still setting the values for
the
ps that quote is from
http://tapestry.apache.org/tapestry-tutorial.html
On 11/12/2011 9:04 PM, Paul Stanton wrote:
Hi all,
I found a nasty situation where some xhr requests were running into
nullpointers on properties of persistent page properties/fields. My
theory being that there is some
