db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mse...@dbrack01.segel.com
Subject Re: Derby and replication
Date Tue, 18 Sep 2007 18:37:39 GMT
You can have asynch replication without having any data loss. Or rather the probability of
data loss is minimal.
Sent via BlackBerry by AT&T

-----Original Message-----
From: "David Van Couvering" <david@vancouvering.com>

Date: Tue, 18 Sep 2007 10:39:49 
To:"Derby Discussion" <derby-user@db.apache.org>
Subject: Re: Derby and replication


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 <fesh@verarisoft.com> 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 <admarginem@gmail.com> 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
> fesh@verarisoft.com
> 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.
>
>
>
Mime
View raw message