Book a Demo

Author Topic: Replication on DBMS  (Read 3792 times)

Luis J. Lobo

  • EA User
  • **
  • Posts: 252
  • Karma: +0/-0
  • IT Consultant
    • View Profile
Replication on DBMS
« on: September 11, 2009, 10:01:31 pm »
In the EA_Deployment whitepaper and other resources talking about repository replication, all references are about MS Access.

It's possible to create, for example, 2 Oracle DBs with bidirectional and transactional replication?

Scenario: one user connected to DB1, other connected to DB2. Changes made in DB1 are reflected in DB2 (refreshing) and vice-versa.

Is this possible or not? Why not?

This, in combination with the "Require user lock to edit" mode, sure make much more easy the deployments that actually needs the controlled packages (under external VC) to do the same...

Thanks!

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Replication on DBMS
« Reply #1 on: September 14, 2009, 03:34:32 pm »
I don't think two way replication is possible from within EA.
Yo could try to set this up on the database only (so without changing anything in EA), but I don't have any experience on that field.
What definitely works is using an external VC to keep both databases in synch.
If you do a checkout of a package EA will first do a "get latest version". That should ensure that you are always editing the latest version of your package.

Geert

Luis J. Lobo

  • EA User
  • **
  • Posts: 252
  • Karma: +0/-0
  • IT Consultant
    • View Profile
Re: Replication on DBMS
« Reply #2 on: September 14, 2009, 05:50:20 pm »
Thanks, Geert.

I have experience working with EA with several SCMs, and works fine. But puntually we experienced problems and when the repository becomes big it is not very "usable".

My idea is to simplify the administration and the time used in every check-out / check-in.

People working under DB replication (in the data layer, of curse, not by EA replication) are "virtually" on the same DB. No locks are needed and paralell development is more realistic. If someone needs to lock something, he use security locks.

I think this improves the process and simplify the EA management.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Replication on DBMS
« Reply #3 on: September 14, 2009, 06:02:05 pm »
Luis,

I've found that the trick to keep the VC performance in control is to have small enough controlled packages.
I've seen that large packages take a long time exporting/importing to xmi.
Can you elaborate on the problems you have with version control, and why this is not usable in a big repository?
The reason I'm asking is that I'm thinking about setting up version control on my current project. We already have a pretty big model (~50.000 elements) so if there are fundamental problems using version control on big repositories I'd like to know.

Geert

Dermot

  • EA Administrator
  • EA User
  • *****
  • Posts: 591
  • Karma: +7/-0
    • View Profile
Re: Replication on DBMS
« Reply #4 on: September 16, 2009, 04:07:50 pm »
Hello Luis,
EA does only support replication on the .eap files.  We do suggest you check with DBMS provider as there are options for some of the main DBMS systems for replication - these should not affect EA.
Alternately I suggest you check the recent updates to the DBMS interface to allow for Lazy Load and WAN Optimisation.  Combined, these both reduce significantly the speed and throughput across a WAN interface.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 13523
  • Karma: +574/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: Replication on DBMS
« Reply #5 on: September 16, 2009, 04:09:42 pm »
Dermot,

I think Luis was referring to the performance of the xmi import/export when using version control.
I'm afraid the lazy load and WAN Optimisation won't help much in that area.

Geert