Bogdan and Stan, On Thu, Jun 30, 2011 at 11:14 AM, Bogdan-Andrei Iancu <[email protected]>wrote:
> Hi Stan, > > > On 06/30/2011 08:48 PM, Stanisław Pitucha wrote: > >> On 30 June 2011 17:25, Bogdan-Andrei Iancu<[email protected]> wrote: >> >>> Revision: 8105 >>> http://opensips.svn.**sourceforge.net/opensips/?rev=** >>> 8105&view=rev<http://opensips.svn.sourceforge.net/opensips/?rev=8105&view=rev> >>> Author: bogdan_iancu >>> Date: 2011-06-30 16:25:18 +0000 (Thu, 30 Jun 2011) >>> >>> Log Message: >>> ----------- >>> - fixed race between UPDATE and DELETE when using DB_ONLY mode (one >>> processe can update a record, while timer proc tries to delete it). The >>> result is loosing contacts from database. The fix is to use REPLACE (if >>> available on DB level) instead of UPDATE (as records may be missing). >>> Based on an original idea from patch #2969454; Credits go to Stanislaw >>> Pitucha >>> >> I think a bit too much stuff was stripped. Now the old db schema is >> used without any control from the user. >> That means there's no unique key to generate the conflict >> (update/replace happens only on key collision) on insert >> > Thanks for reminding me on that - I almost forgot to update the DB schema > and to add the unique key constraint as you mentioned - just did that > > > and no way to >> turn off the "atomic" updates from the config if you want the old >> schema... Unless it's properly documented in the manual it might cause >> some really bizarre situations for people using DB_ONLY. >> > What kind of side effects are you referring at ? My idea was to try to > automatically fix the problem (when DB_ONLY is used), transparent for the > user. Of course, it is not a big deal to add the config switch for that, but > I don't see why you should disable it and run a buggy code :D. > > Thanks and regards, > Bogdan > > > -- > > One major issue with enforcing a unique index on username,contact is that if a client comes in and is using a Path: header, the contact address is irrelevant and not "fixed up" so two accounts from behind NAT's both on the 192.168.1.x range will have conflicts resulting in one endpoint being silently dropped. I believe this is also a problem with the internal hash table too. -Aron Aron Rosenberg Lifesize / Logitech
_______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
