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
