I never saw a response to this, but it does seem like a problem. I don't love the idea of a special exception used purely to handle control flow, but I can't think of anything better off-hand.
--tim On Sat, May 22, 2010 at 8:05 PM, Tal Liron <[email protected]>wrote: > Hi Jerome, > > > 2. There is a TaskService associated to your application that you could > > leverage. It separates threads usage from tasks to process (such as > > committing responses). > > I've tried this, but there is a concurrency problem with this pattern in > ServerResource -- > > If I set autoCommiting to false during a ServerResource.get() and put my > task on a separate thread pool, then my own task might try to update the > response at the same time as the upper parts of the call stack > (Finder.handle(), for example) also try to update the response according > to my return value from get(). Both threads might be doing it at the > same time, and the response ends up corrupted (no concurrency > exceptions, but it's mismatched status/entity, for example). > > What would be the correct way to defer a response from within a > ServerResource? > > My thought is that there should be a way to return from get() while > signaling to the rest of the call stack that I am handling the response. > A null won't work, because it internally signifies an unavailable > entity. Perhaps a new kind of ResourceException? > DefferedResponseResourceException? > > -Tal > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2612147 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2623441
