23 Dec
2011
23 Dec
'11
2:39 p.m.
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'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.
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.
Andreas
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.