Hello,
On 12/23/11 1:39 PM, Andreas Granig wrote:
Hi,
On 12/23/2011 12:28 AM, Daniel-Constantin Mierla wrote:
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.
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.
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