Marc Weber wrote:
optimistic SQL concurrency violation
Maybe you can use pessimistic locking or such. Then the database is more
likely to block rather than rollback (?)
If you use pessimistic locking, you can still run into a deadlock, which
is a problem when the surface language doesn't even expose locking to
the programmer. I would want to see an automatic restart in such cases.
No minimum heap setting yet. This also wouldn't get around SQL
concurrency failures.
You don't get around them anyway.
I don't understand this line. I meant that a minimum heap setting
wouldn't remove the need to do some explicit handling of concurrency
failures, such that the most natural response seems to be a restart.
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.
Yes, this seems like a good, simple idea. Would you mind opening a
Mantis bug asking for this?
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.
I didn't say "huge." :-)
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.
Couldn't you just as easily write a C function that takes "options" as
input and then always executes "verify-pay-confirm" with those options?
That would make sure the Ur/Web layer can't introduce zany
non-transactional behavior.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
