> "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 this meant that multiple XHR requests from the same session > would be queued up and processed one at a time on the server. I'm pretty sure that would be considered a defect. XHR requests aren't the only asynchronous requests that use the session. Consider an authenticated image gallery where the browser is trying be efficient and load multiple images concurrently? If Tapestry only allowed one image to be processed at a time that could kill the user experience. > Could someone clarify what is meant by the above quote and whether it > applies to 5.1.x or just 5.2+? It applies to 5.x. The quote is talking about managing your page and component life cycles. It makes sure that your property values don't leak from one render request into another. Tapestry can render the same page/component/event concurrently for as many threads as you have available. What it's not saying is what is important. Session attributes, like your page and component classes, are also a shared resource. Tapestry does what it can to ensure that they are stored atomically and shared between clustered servers. But what it can't do is guarantee that two concurrent threads using the same session aren't going to clobber the session object they share. How could it without serializing requests to the same session? And that's a non-starter. > Also, is my approach of synchronization using the session object the best > solution here? It really depends on what you want. If you don't care that a user's requests will be serialized then your solution is fine. Locking the session for the whole event is a pretty broad stroke though. You might narrow your synchronization to where the conflicts can actually occur, for instance during the creation of your persisted object. Josh On Sun, Dec 11, 2011 at 2:04 AM, Paul Stanton <[email protected]> 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 access to fields of a persistent field in XHR > request A, while XHR request B is still setting the values for the field. > > I always assumed that tapestry 5.x handled thread safety for you? > > "Tapestry also shields you from the multi-threaded aspects of web > application development. Tapestry manages the life-cycles of your page and > components objects, and manages the fields of the pages and components in a > thread-safe way. Your page and component classes always look like simple, > standard POJOs." > > I had assumed this meant that multiple XHR requests from the same session > would be queued up and processed one at a time on the server. > > This appears to not have been the case, and now having every XHR event > listener synchronized on the session I no longer seem to get the problems. > > Could someone clarify what is meant by the above quote and whether it > applies to 5.1.x or just 5.2+? > > Also, is my approach of synchronization using the session object the best > solution here? > > Thanks, Paul. > > ps I'm stuck on tapestry 5.1.0.5 for this project. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
