On Thursday 30 July 2009, Razvan Pistolea wrote: > > Why a virtual db module? > > Until now all modules requiring db support had only one (real) db_url connection and it was bad if that connection went down. > > Here is where virtual db module comes in: > it provides to other modules a (virtual) db_url that maps > multiple (real) db_urls to real dbs. > > The real connections are handled transparently to the module using the virtual url. > Now if the current real connection goes down the virtual db_url will > just switch to a new one transparently to the module, giving uninterrupted db access. > This mode is called failover and can be used for write and read > operations.
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. 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? 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. -- Dan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
