2 Replies Latest reply on Aug 11, 2003 8:28 AM by erikdhansen

    JMS/MDBs right for me?

    erikdhansen

      I'm looking at trying to maintain database synchronization across several separate databases which are all controlled by individual instances of JBoss.

      Basically, each JBoss instance handles data input for it's own database, but certain database operations need to be replicated to all other database instances.

      I'm considering doing this via JMS and MDBs. The way I see it, I'd need clients for each database which subscribe to topics on all of the other JBoss servers so that as data is entered into the database, messages are published to the topics which the clients then receive and pass along to the local JBoss instance.

      The other option is to have only one JBoss instance responsible for messaging where all messages from all remote clients (most likely session EJBs in the remote servers) are sent and that JBoss server then publishes the message to everyone else.

      I like the first approach as it's more symmetric than the second, but I'm not sure how I'd handle the dynamic addition of more remote databases and the resulting dynamic addition of listening clients on each server.

      Very interested in your thoughts.

        • 1. Re: JMS/MDBs right for me?

          You know JMS is asynchronous and although you can
          guarantee message delivery, you cannot guarantee when?

          I suspect you would want some replication that is more
          closely tied to the transaction commits.

          Regards,
          Adrian

          • 2. Re: JMS/MDBs right for me?
            erikdhansen

            The replication doesn't need to be immediate -- as long as it happens. A certain amount of lag time is acceptable in this application -- and the amount that we're allowing for would be (I would think) well within the delay time I presumed I might see with JMS...maybe not, though -- what kind of delay can I expect?

            I don't want to tie up the local user waiting on synchronous replication to several remote locations. Once the commit happens locally, they can continue on. The remote sites can be updated afterwards.

            There will be periodic database auditing to ensure that all is well.