Results 1 to 5 of 5
  1. #1
    Join Date
    Jan 2006
    Posts
    13

    Unanswered: Transactional Question

    hi,
    Is immediate updating from subscribers to the publisher the same as bi-directional transaction replication? if not what is bi-directional transaction?
    Tks for any help.

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    No, Updating Subscribers and bi-directional replication are similar in concept, but radically different in implementation.

    Updating subscribers are implemented in "one way" replication using RPC calls. The subscriber is 100% dependant on the publisher. Triggers on the subscriber tables force an update on the publisher table via an RPC call to the publisher. This is conceptually easy, guarantees correctness without user intervention, but it uses lots of bandwidth and CPU.

    Bi-directional replication effectively has two (or N) publishers... Each updates and publishes. This gives maximum autonomy, but it can requires LOTS of manual intervention when the publishers get into a "fight" due to simultaneous updates to the same row.

    -PatP

  3. #3
    Join Date
    Jan 2006
    Posts
    13
    ok so based on BOL, i should only implement bi-directional using scripts. Nothing else. Correct?

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    This is a question that is WAY too complex for a simple answer. There are literally thousands of options that can be applied in some unholy number of combinations, and there are often more than one combination that will work well for a given situation.

    I'd investigate merge replication to see if that will do what you need. Be sure that you understand what replication conflicts are, and how they are resolved in different scenarios... They can kill you if you are caught unprepared!

    Replication is an area where I almost always recommend professional advice. You need someone that understands replication to come in and analyze your scenario. There are many choices to be made, and some of them can be critically important to your long-term sanity. While a knowledgable person isn't going to be cheap, the consequences of serious mistakes can be expensive in ways that you can hardly imagine at the outset!

    -PatP

  5. #5
    Join Date
    Jan 2006
    Posts
    13
    Tks for the reply Pat. I understand what u mean. I had tested merge replication on my app and the latency of merge is a factor which cannot be accepted at this moment. Thats why i decided to research on bi-directional transactional replication.
    Here's a description of the requirements.
    I have server A and server B. server A will be the main server and B the backup. Data will be process at server A under normal settings and B will just get updates from A. However when A goes down, B will become the main server. Now the data will be process at B. When server A goes live again, data will need to be process at A again and with all data in-sync with B. And all these has to be automated, except for making A live again.
    What u think of bi-directional trans repl for this?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •