Douglas Garstang wrote:
You can quite clearly see that MySQL does NOT return a row, and OpenSER happily goes and does an insert then. I can't understand why MySQL >then complains about a duplicate key error. Why would it do this when the row wasn't found, and presumably the key doesn't exist?
your trace shows two queries:
- a DB authentication
- a usrloc updated.
based on the information from cache, openser knows if it should do an update or insert. the problem is if you use 2 opensers on same DB, each server, based on private cache, will know they have to do insert (the contact is not in cache and DB). and you will end with 2 duplicated inserts.
Bogdan, thanks for the reply. I'm don't quite understand. I'm using db_mode 1, which the docs say writes all updates immediately to the database. A 'openserctl ul show' still shows cached entries though. Why? Is db_mode 1 supposed to cache at all? Which db_mode should I use so that I can have two or more OpenSER systems safely accessing the same database?
all db_mods from 0 to 2 use mem cache - the difference is when the DB is updated with changes from cache. in mod 1 the changes from cache are immediately written into DB.
the only non-cache db mod is 3, but this is available only in the devel branch - read carefully the docs to understand the implications of this mod.
regards, bogdan