User Tools

Site Tools


Registry Replication

Author Daniel Fisher
Date 2005/05/24


Problem Statements

  • Registry replication uses an external java process to harvest changes.
  • Replication occurs via an execute/sleep process, rather than asynchronously.
  • Replication occurs at approximately one record per second, which is too slow in some cases.
  • The same record can be processed multiple times, which is unnecessary and slows replication.

Functional Requirements

OAQ Listener:

  1. Read payload from an Oracle Advanced Queue.
  2. Get person/service/group data from the Registry Query bean.
  3. Determine if the record has already been processed with the Registry Change Bean.
  4. If the record has not been processed, enqueue the person/service/group with the Registry Enqueue Bean so it can be processed further. If it has already been processed, take no action.
  5. Do not acknowledge payload from Queue until the message has been processed.

Message Driven Bean:

  1. Read payload from JBossMQ (contains Person, Service, Group, Entitlement Object).
  2. Get person/service/group/entitlement data from the Registry Query bean.
  3. Lock the MDB so only one record can be processed at once (to ensure correct changes are replicated).
  4. If the record has not been processed, send it to the Registry Change Bean so it may replicate downstream. If it has already been processed, take no action.
  5. Unlock the MDB and acknowledge the message.

Nonfunctional Requirements

  1. OAQ component must be written as a clustered singleton JBoss service.
  2. JBossMQ component must be written as a Message Driven Bean.


  • Functional Requirement 4 (used to be: Do not acknowlege payload from Queue until the Registry Change Bean has responded that the message has been processed.) effectively limits RegistryRepl to only process one record at any given time. This is because the MessageListener will not get another message until the current message is acknowledged. We will still experience a large queue of changes from the Registry as we do currently. Building records concurrently is the only way to speed up replication as record building is the only real bottleneck. To do this, we must acknowledge the message before calling the RegistryChange Bean. So, what do we want: slow and reliable, or fast and less reliable. We can make concurrent building of records more reliable if we can publish messages back to the queue as well as block on RegistryChange errors (bean is not deployed or something similar). — 2005/06/09 17:13
middleware/devel/ed/registry-repl.txt · Last modified: 2015/06/01 12:02 (external edit)