On 19 Aug 2010, at 14:40, Randy Watler wrote: > Scott, > > Can you comment on the JIRA issue? > > I am not sure if you think this issue is best fixed in the widget code or on > the server. If we want to fix it on the server, (as you appeared to be > leaning in previous comments), we'll need some ability to retry a request. > This is not easy to accomplish in all cases since the HTTP responses my be > committed when the exception is caught wrapping the transaction. I am not > sure if it is committed or not in this case, (something to look I suppose). > As I noted, I believe there is a race condition in the widget code that is > the real issue here. We could try to eliminate that or handle the error > condition and retry from the widget. > > Thoughts? I'd like to take a crack at fixing this whichever way you prefer > ASAP.
I don't think we can rely on widgets being coded "correctly" - so we shouldn't generate a 500 error, but instead handle things more gracefully even if the widget is written so as to make all kinds of odd simultaneous requests. As you say it wouldn't be trivial to trap and retry as the requests are coming in simultaneously on different server threads and wrapped in separate transactions. I wonder if we could check in the exception case to see if the object was created anyway, and then return 200 instead of 500 and just log the issue? > > Randy > > Scott Wilson wrote: >> Hi everyone, >> >> I've just updated the Pluggable Persistence Branch so it is ready to merge >> into the main trunk. >> >> Currently there is one outstanding issue with the branch; see: >> >> https://issues.apache.org/jira/browse/WOOKIE-145 >> >> We will also need to review the documentation to ensure it is consistent >> with the new persistence mechanism and its configuration. >> >> However at this point I would prefer to manage these issues within the trunk >> rather than continue to maintain a separate branch, so I am proposing to >> merge in the pluggable persistence branch. >> >> What do you think? >> >> S >> >
