12 Dec
2011
12 Dec
'11
11:32 a.m.
Hello,
On 12/12/11 10:46 AM, Alex Hermann wrote:
On Monday 12 December 2011, Daniel-Constantin Mierla
wrote:
this seems to need also lot of review. It may happen that functions do
db operations inside locks or with some temporary states, so an eventual
interruption of config file execution has to make sure that the cfg
function doing the db operation finishes, to avoid deadlocks, leaks ...
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
How about calling an error_route block when a DB error
occurs. Maybe with the
proper return stack setup so the admin is able to return to the statement
following the failed db query if he doesn't want to end the processing with
some failure reply.
I have been thinking about this as well. We could
implement a db_ping
function so we could test in the routing script before calling functions
that use the DB. It's harder with stuff that happens in the background,
like ACC and SIPTRACE. I don't know what happens with them if the
database fails.
one option would be to set a config env variable, like db_error,
which
is set by the db modules on error. Then can be checked in the config and
act accordingly. This will require touching the db modules.
Alternative is to propagate some return codes up to config file, but
this will require changes in all modules interacting with database,
including the db modules.