Excerpts from Adam Chlipala's message of Sun Nov 28 21:58:18 +0100 2010: > That's right. The runtime system will also restart if an optimistic SQL > concurrency violation is detected, when certain errors are signaled, etc..
Don't know yet whether that's smart behaviour. How exactly is determined how much heap will be allocated for a request? There are some cases where you don't want to retry; Some payment systems redirect customers using a "return" url which tells the web system that the customer has entered all the data. Then the web system is supposed to verify and confirm the data - because the return url parameters can be manipulated by the user. However you can't run that confirmation query - which is typically a http request - twice. The second time they'll return an error telling you "that transaction id has been used previously". Worse: Because urweb rolls back everything db related you don't even have traces about it. So the custmer has to pay - and you don't have an order. I can see 3 solutions: a) write a layer between urweb and the payment service which is caching the confirmation results. Bad: You can't use urweb for writing it. You could do this caching in C as well - but I'd like to use a higher order language to get my jobs done.. b) tell urweb to use a huge heap size so that its very unlikely that the issue appears - is there a project configuration option specifying a min heap size? c) never fail for heap reasons. Use a linked list of heap blocks. If one is full allocate another one which is large enough and continue. About the pointer; I'm lucky that it worked. http://gitorious.org/some-urweb-utility-libraries/uw-process/commit/ff620ea22b3209c73482c50ec24909ea581ac4ab Marc Weber _______________________________________________ Ur mailing list Ur@impredicative.com http://www.impredicative.com/cgi-bin/mailman/listinfo/ur