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 at 9:39 AM, Josh Canfield <joshcanfi...@gmail.com> wrote: >> "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 <p...@mapshed.com.au> 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: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
