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:
1) a DB authentication
2) 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
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
