[OpenSIPS-Users] [OpenSIPS-Devel] [NEW] Virtual DB module
Razvan Pistolea
razvy000 at yahoo.com
Fri Jul 31 16:53:46 CEST 2009
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 <thomas at gelf.net> wrote:
> From: Thomas Gelf <thomas at gelf.net>
> Subject: Re: [OpenSIPS-Devel] [NEW] Virtual DB module
> To: devel at lists.opensips.org
> Cc: users at 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
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>
More information about the Users
mailing list