2 Jan
2012
2 Jan
'12
12:20 p.m.
Hello,
On 12/23/11 1:39 PM, Andreas Granig wrote:
Hi,
On 12/23/2011 12:28 AM, Daniel-Constantin Mierla wrote:
Of course
you can never rule out admin errors or application errors, but
anyways I'll highly favor a more resilient approach.
I encountered several cases when things can go bad at database layer
while doing cross replication along with t_replicate(). Finding a
solution would be a good thing. The fact is that these situations should
be corner cases, so there has to be a solution not impact the normal
operation mode.
If
someone is messing with the db, kamailio shouldn't try to correct
admin mistakes.
It was just an example, I haven't gone to all corner cases
that can
happen from human or (self or different) application errors. There were
couple of similar reports in the past, related to conflicts of
insert/update, update/insert, delete/update a.s.o. cases, so I proposed
to go for a portable solution, not for one which valid to a db driver
only -- configurable or not, is different thing than the specific topic.
I've tried to reproduce the most obvious scenario, which is registering
a subscriber, delete it from the underlying db table, then re-register
again. The expiry value in the cache is refreshed, but it's never
written back to the db table. There are most likely other, more subtle
scenarios, and our customers approved that they didn't mess with the db
manually. The state was always CS_SYNC and Flags was 0.
I don't know the details of the srdb layer, but probably it's possible
to find a way to return the "rows affected" after an update in order to
know whether to try an insert afterwards. Would be possible with mysql,
not sure about pgsql, oracle, dbtext etc. We'll take a look how we could
tackle that.
Mysql has affected row and it is exported by db_mysql module, not sure
about the other drivers.
I don't think that a log message would help very much, because kamailio
won't know about the missing entry in the db (unless you evaluate the
result of the update), at least in this particular case.
Yes, kamailio does not
know, I know, seems it is what we try to solve --
first how to make it aware and then do some actions (like writing a log
message).
Perhaps the best for the moment is to detect at startup and rely on db
api capabilities and use replace/affected_rows a.s.o. when they are
available, in the best efficient order -- a module parameter can give
admins the power to decide over the auto-detect.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda