> optimistic SQL concurrency violation Maybe you can use pessimistic locking or such. Then the database is more likely to block rather than rollback (?)
> No minimum heap setting yet. This also wouldn't get around SQL > concurrency failures. You don't get around them anyway. I know that I can't prevent all reasons for restarting. But I can try to minimize them. Having a project option setting the "minimum heap size" seems to be a way to reduce some risks of restarting. > This would be extra complexity and a new performance hit with no > observable benefit for almost all cases, so I'm inclined against it. Ok. I don't see such a huge performance overhead. The overhead will be evaluating one cheap condition compared to restarting. But I agree that its not worth the effort. Anyway: How do you think about adding a minimum heap size option? Probably I can do so myself when needed. About the traces I was wrong: You could use uw_register_transactional and use a rollback callback to trace something. Anyway: Those are the use cases for Process.exec: run a php or ruby script and insert something into a database without having to code C. so you can do: ok <- Process.exec "verify-pay-confirm options" and put all the ugly caching into verify-pay-confirm and be done. Se next thing to be done is writing JSON encoding / decoding so that you can pass data easily. Eg json <- JSON.parse "string" switch type (json) of dict -> list -> int -> ... Marc Weber _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
