On 4/29/2014 8:38 AM, Dimitry Sibiryakov wrote: > 29.04.2014 14:24, Carlos H. Cantu wrote: >> You are right about the DB design, but that's up to the user. You >> dont and should not worry with this. > But the one who implements built-in replication will have to worry about > conflict > handling, constraint failure and so on. > In the case of synchronous replication it is simple - you just raise > error and the rest > is up to user. Asynchronous replication is going to be more tricky. > It's a pity, but the journaling code that Borland ripped out in their failed attempt at a write-ahead log would have been ideal for master/slave replication. In a nutshell, what a page was changed, a second BDB was allocated to hold page changes; if the buffer filled, then the page itself was used. Before the actual page was written, either the page or the set of page change delta was sent to the journal (which would be the slave in replication). As all of the semantic checking had already been performed, application at the slave was simple, straightforward, and automatically followed careful write ordering.
But I suspect the code is long gone and probably next to impossible to reconstruct as it was part and parcel of the origin Interbase design and implementation. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
