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 > > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
