[OpenSIPS-Devel] [NEW] Virtual DB module

[Razvan Pistolea]

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
>