You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Robert Coup <rc...@ec.auckland.ac.nz> on 2003/12/01 00:37:39 UTC
Re: Object replication vs RDBMS replication (little off topic)
Me too.
we have an application underway which will require some offline operation. While
it won't have masses of conflicting stuff, unique key generation would be nice.
However, I expect the offline abilities to be expanded in future, which would
make things more messy :)
Thanks,
Rob :)
Quoting Jason Pyeron <jp...@pyerotechnics.com>:
> ditto.
>
> we have two (2) applications under way right now, which we want to do
> something similar.
>
> 1) n locations connected by a 90% up slow link, these locations need
> access to each others information, and not to conflict.
>
> 2) a port of bugzilla, which will allow offline entry/submission
>
> -Jason Pyeron
>
> On Sun, 30 Nov 2003, Colin Kilburn wrote:
>
> > Gustavo,
> >
> > I expect to have a project soon that will require some replication,
> although perhaps with differing requirements, but I'm sure there'll be some
> overlap in requirements as well as challenges. At minimum I'd be interested
> in discussing issues and approaches in this arena "soon" (I'm currently very
> tied up trying to finish another project.)
> >
> > What results from these efforts (or at least parts of them) may be generic
> enough to be useful to others. Anyone else?
> >
> > Colin Kilburn
> >
> > gfaerman@fys.com.ar wrote:
> >
> > >Hi all,
> > >
> > >Weâve being using OJB for a while and we do like it.
> > >While we depart from the old paradigm (delegating the "important" stuff to
>
> > >the RDBMS) and we delegate OJB the real work, some
> > >opportunities/challenges come to our mind.
> > >And since data/object replication is one of those opportunities, we would
>
> > >like to address in a new project. We believe OJB is ready for a job like
> > >this.
> > >
> > >Letâs say we have some data collection apps running in notebooks
> offsite.
> > >Thanks to OJB, the app runs on almost any RDBMS in every notebook (hsql,
> > >mysql, postgresql or any $$ vendor base rdbms) an in a main site storing
> > >the objects again in an opensource or $$vendor base dbms.
> > >
> > >Once the data collectors have a network connection available (either WAN
> > >or LAN) we would like them to "replicate" their objects with the main site
>
> > >or with other partners. Scheduled or ad-hoc replication, it just doesn´t
>
> > >matter. OJB would do it no matter when or where.
> > >
> > >The apps have some business objects that will remain with little or no
> > >changes through their life cycle (like the old master tables) ; some
> > >others will face heavy updates (customers service requests).
> > >
> > >If any of you are familiar with it, Lotus Notes/Domino type of replication
>
> > >is the best model of the replication mechanism we would like to implement
>
> > >in this project (but remember, at an object or better business object
> > >level replication, not record/document level replication).
> > >
> > >Let´s dream for a minute: OJB will let us replicate objects across
> > >different dbms, without even having the same schema (due to the
> > >repository.xml mapping magic!!!!)
> > >
> > >Among some other things, we will need to take care of things like unique
> > >ids across db replicas ( sequencers ), differential replication,
> > >replication conficts etc.
> > >
> > >Any frameworks or ideas out there? Any volunteers to start an "OJB
> > >replicator" contribution to this great framework?
> > >
> > >Finally and again: Thanks Thomas and the whole OJB team!.
> > >
> > >Best regards,
> > >
> > >Gustavo Faerman
> > >Buenos Aires, Argentina
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron http://www.pyerotechnics.com -
> - Partner & Sr. Manager Pyerotechnics Development, Inc. -
> - +1 (443) 451-2697 500 West University Parkway #1S -
> - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, purge the message from your system and
> notify the sender immediately. Any other use of the email by you
> is prohibited.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Object replication vs RDBMS replication (little off topic)
Posted by gf...@fys.com.ar.
Robert,
Your are right. Unique key generation (or I might say object's unique id
generation) is a crtical issue here. We are looking into a couple of
algorithms here to address this. It means we would need to delegate OJB?s
sequencer a "key" function. This unique object id might work across
replicas letting the replicator to identify objects replicas across
different object repositories.
Regards,
Gustavo.
Robert Coup <rc...@ec.auckland.ac.nz>
30/11/2003 08:37 p.m.
Please respond to
"OJB Users List" <oj...@db.apache.org>
To
OJB Users List <oj...@db.apache.org>
cc
Subject
Re: Object replication vs RDBMS replication (little off topic)
Me too.
we have an application underway which will require some offline operation.
While
it won't have masses of conflicting stuff, unique key generation would be
nice.
However, I expect the offline abilities to be expanded in future, which
would
make things more messy :)
Thanks,
Rob :)
Quoting Jason Pyeron <jp...@pyerotechnics.com>:
> ditto.
>
> we have two (2) applications under way right now, which we want to do
> something similar.
>
> 1) n locations connected by a 90% up slow link, these locations need
> access to each others information, and not to conflict.
>
> 2) a port of bugzilla, which will allow offline entry/submission
>
> -Jason Pyeron
>
> On Sun, 30 Nov 2003, Colin Kilburn wrote:
>
> > Gustavo,
> >
> > I expect to have a project soon that will require some replication,
> although perhaps with differing requirements, but I'm sure there'll be
some
> overlap in requirements as well as challenges. At minimum I'd be
interested
> in discussing issues and approaches in this arena "soon" (I'm currently
very
> tied up trying to finish another project.)
> >
> > What results from these efforts (or at least parts of them) may be
generic
> enough to be useful to others. Anyone else?
> >
> > Colin Kilburn
> >
> > gfaerman@fys.com.ar wrote:
> >
> > >Hi all,
> > >
> > >Weâ??ve being using OJB for a while and we do like it.
> > >While we depart from the old paradigm (delegating the "important"
stuff to
>
> > >the RDBMS) and we delegate OJB the real work, some
> > >opportunities/challenges come to our mind.
> > >And since data/object replication is one of those opportunities, we
would
>
> > >like to address in a new project. We believe OJB is ready for a job
like
> > >this.
> > >
> > >Letâ??s say we have some data collection apps running in notebooks
> offsite.
> > >Thanks to OJB, the app runs on almost any RDBMS in every notebook
(hsql,
> > >mysql, postgresql or any $$ vendor base rdbms) an in a main site
storing
> > >the objects again in an opensource or $$vendor base dbms.
> > >
> > >Once the data collectors have a network connection available (either
WAN
> > >or LAN) we would like them to "replicate" their objects with the main
site
>
> > >or with other partners. Scheduled or ad-hoc replication, it just
doesn´t
>
> > >matter. OJB would do it no matter when or where.
> > >
> > >The apps have some business objects that will remain with little or
no
> > >changes through their life cycle (like the old master tables) ; some
> > >others will face heavy updates (customers service requests).
> > >
> > >If any of you are familiar with it, Lotus Notes/Domino type of
replication
>
> > >is the best model of the replication mechanism we would like to
implement
>
> > >in this project (but remember, at an object or better business object
> > >level replication, not record/document level replication).
> > >
> > >Let´s dream for a minute: OJB will let us replicate objects across
> > >different dbms, without even having the same schema (due to the
> > >repository.xml mapping magic!!!!)
> > >
> > >Among some other things, we will need to take care of things like
unique
> > >ids across db replicas ( sequencers ), differential replication,
> > >replication conficts etc.
> > >
> > >Any frameworks or ideas out there? Any volunteers to start an "OJB
> > >replicator" contribution to this great framework?
> > >
> > >Finally and again: Thanks Thomas and the whole OJB team!.
> > >
> > >Best regards,
> > >
> > >Gustavo Faerman
> > >Buenos Aires, Argentina
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: ojb-user-help@db.apache.org
> >
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> - -
> - Jason Pyeron http://www.pyerotechnics.com -
> - Partner & Sr. Manager Pyerotechnics Development, Inc. -
> - +1 (443) 451-2697 500 West University Parkway #1S -
> - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 -
> - -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, purge the message from your system and
> notify the sender immediately. Any other use of the email by you
> is prohibited.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org