I see. Well, how about this:
Perhaps setAutoCommit(false) might be the wrong approach. If anybody else along the chain tries to commit, it should fail somehow. How, then, would response.commit() know when it's time to really, truly commit? My idea is to make a commitment to commit (ha!) via a kind of token, which would identify the committer. The flow would be something like this: Object token = response.deferCommit(); ... >From now on, the response has a flag telling it that commitment is deferred, >and it will fail on all commit() calls, unless the token is provided. ... Later, on some other thread: ... response.commit(token); ... The above will actually commit, because the token was provided. Hopefully my test code can be turned into a unit test for whatever solution is found (though reliable unit tests for race conditions are notoriously hard to get right). > My understanding of Jerome's e-mail of 2010-Aug-30 (has it really been that > long?) is that it's not sufficient to unwind the stack, whether by > exception or by testing response state. The main problem is arranging for > the calls to afterHandle to occur in a different thread. These are > calls that would have been executed on a committed response as part of the > normal stack unwind. > > While it *might *be a reasonable implementation choice to use an exception > internally, it's not a real exception that can be allowed to propagate > arbitrarily, because it's OK, not exceptional, for the original thread to > return without a committed response. > > This is a tough problem. > > --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2899593
