Hi Dan Hi Thomas Thank you for your interest in my module and associated db dilemmas & shortcomings. As you have pointed out: - there is not much that can be done NOW without db transaction support. - db virtual module is a simple (hopefully helpful) wrapper. Best regards, Razvan Pistolea
--- On Fri, 7/31/09, Thomas Gelf <tho...@gelf.net> wrote: > From: Thomas Gelf <tho...@gelf.net> > Subject: Re: [OpenSIPS-Devel] [NEW] Virtual DB module > To: de...@lists.opensips.org > Cc: users@lists.opensips.org > Date: Friday, July 31, 2009, 4:04 AM > Dan Pascu wrote: > > On Thursday 30 July 2009, Razvan Pistolea wrote: > > How does this work with operations that are separate, > but still represent a > > single logical operation, like for example writing > usrloc, or dialog data into > > the database not in real time but on a timer, where > multiple records are > > inserted at a time. If a connection fails in the > middle of an operation, some > > records will end up in one database and some in > another and OpenSIPS will have > > troubles finding the information later. Without having > transaction support for > > such operations, so that all the inserts that belong > together fail and are > > retried together on the next connection, it would be > problematic. > > I agree that transaction support would be not only a good > idea, I > consider it really important - and probably not that hard > to add (ok, > this depends strongly on how all these backends ar > abstracted - it could > also be really tricky...). > > > Another issue is that even if transaction support > would be implemented, there > > is still an uncertainty where the data is. If my > usrloc or dialog data was > > saved over multiple connections, after a restart, from > where is OpenSIPS > > supposed to read the data? > > From the active one - of course this requires your > databases to be > somehow "perfectly" synchronised. > > > I can see that this can work fine for read operations > assuming that the > > databases are synchronized by external means and > wherever you go you get the > > same information, but for write I do not see where the > aggregation layer is to > > assure that the data is synchronized and consistent. > > That's not OpenSIPS job - it's up to who is configuring it > to take > care of synced DBs and such things. OpenSIPS has to drop > it's queries > somewhere - nothing more. And multiple configured DBs > allows you to > easily take down one DB server for maintainance without > interrupting > the service. > > I consider this a very worthful addition. And there is not > so much > trouble you can cause if OpenSIPS is either not inserting a > record > or writing it twice to usrloc - after some time everything > will be > fine again. The impact is much less than a "real" > downtime. > > Just my 2 eurocent - please correct me, if I'm wrong! > > Best regards, > Thomas Gelf > > > _______________________________________________ > Devel mailing list > de...@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
