I don't think it matters so much what the architecture is (e.g. peer-to-peer versus client-server or whatever). I think what matters is the use case.
I generally use the word "replication" to imply keeping two instances tightly in sync for high availability. You have asynchronous replication, where there is a time lag and a potential loss of data (this is often used to work across WANs for disaster recover scenarios) and synchronous replication (this is more common, and is used to provide a hot standby in case of hardware or software failure). I generally use the word "synchronization" to represent the use case where you want to keep two databases "in synch" for performance reasons, or because the application using the data may not be able to connect back to the "main" server. Common use cases are * keeping a local database on a mobile client like a laptop or PDA that is a copy of a remote database (think Palm Sync, calendaring apps on your phone, sales force automation, a local copy of a sales catalog, etc.). The POS system discussed here is this kind of model - you keep a local database on the POS terminal and synch it up with the central POS database * Having a local database embedded or on the same machine as a web server or other "edge" server, and this is kept in synch with the Big Database in the back room. This is attractive as it boosts performance without giving up transactional consistency. This is basically a "relational cache." David On 9/18/07, Eric Fesh <[EMAIL PROTECTED]> wrote: > David: > > I've been looking into replication technologies for improvements on a project > that I'm working on... The difference between > replication and synchronization is something I hadn't realized before. Would > synchronization be more appropriate for a > peer-to-peer architecture than replication would be? > > > David Van Couvering wrote: > > I think the responses you have heard so far talk about replication to > > provide availability (HA-JDBC, the ongoing Derby effort). > > > > What you are talking about is basically using Derby as a reliable > > front-end cache to a back-end database where the connection can be > > unavailable from time to time. > > > > What this is about is really synchronization, not replication. > > Synchronization is keeping two sometimes disconnected databases in > > synch. > > > > One product out there that works with Derby is Daffodil Replicator, > > see http://sourceforge.net/projects/daffodilreplica/. It's an open > > source project using the GPL license. > > > > David > > > > On 9/18/07, ad marginem <[EMAIL PROTECTED]> wrote: > >> Hello, > >> > >> I want to develop a program, using derby as a back-end. > >> > >> There will be a POS and a Warehouse module. They will use the same database > >> scheme, but they cannot use the same database because of reliability (in > >> case of broken connection the POS must not stop). > >> > >> So my question is: how to develop such a reliable workflow? Replication? Or > >> maybe there are some other options? If replication - how to implement it? > >> Are there any existing methods to replicate derby database? > >> > >> Thank you! > >> > >> > >> -- > >> по краям > > -- > -- > > Eric Fesh > Software Engineer > Verari Systems Software, Inc. > 110 12th Street North, Suite D103 > Birmingham, AL 35203 > Phone +1-205-397-3141 ext. 3151 > Fax +1-205-397-3142 > [EMAIL PROTECTED] > http://www.verarisoft.com/ > > The information contained in this communication may be confidential and is > intended only for the use of the recipient(s) named above. If the reader of > this communication is not the intended recipient(s), you are hereby notified > that any dissemination, distribution, or copying of this communication, or > any of its contents, is strictly prohibited. If you are not a named > recipient or received this communication by mistake, please notify the sender > and delete the communication and all copies of it. > > -- > > The information contained in this communication may be confidential and is > intended only for the use of the recipient(s) named above. If the reader > of this communication is not the intended recipient(s), you are hereby > notified that any dissemination, distribution, or copying of this > communication, or any of its contents, is strictly prohibited. If you are > not a named recipient or received this communication by mistake, please > notify the sender and delete the communication and all copies of it. > > >
