How Distributed Mailings Work

A distributed mailing is handled as follows: a request to start sending a mailing is received by one of the machines that you have designated as a distributed e-mail server. The machine (the send owner) creates entries in the dps_mailing and dps_user_mailing tables as it would for a non-distributed mailing. In addition, it separates the mailing into batches, creating entries for them in a dps_mail_batch table. Each batch entry specifies the ID of the parent mailing, the starting index of the first recipient in the batch, and the number of recipients in the batch. The dps_mail_batch table also includes a unique_server_id column, which contains the ID of the server that has claimed the batch for rendering.

When another machine that you have designated as a distributed e-mail server is started, it creates or updates a time entry in the dps_mail_server table. Then, at set intervals, the TemplateEmailPeriodicService component on that server does the following:

  1. Updates the timestamp in the dps_mail_server table.

  2. Checks to make sure that the previous machine shown in the dps_mail_server list has not timed out.

  3. If the previous machine has timed out, it clears the uniq_server_id from all of that machine’s in-progress batch mailings, thereby returning them to the pool of unclaimed batches.

  4. Checks the dps_mail_batch table for available batch jobs. If jobs are available, it spawns threads to execute them (unless the threads already exist). You can control the number of threads that are spawned; for more information, see Performance Tuning Considerations for Distributed E-mail.

    The rendering threads use a lock in the ClientLockManager to avoid having two threads claim the same batch (which would trigger a concurrent update exception).

Each thread then does the following:

  1. Claims the first job in the dps_mail_batch table by entering a value in the uniq_server_id column of that table.

  2. Executes the job as it would in a non-distributed mailing, except that it updates the count in the dps_mail_batch table instead of in the dps_mailing table. (This behavior allows the system to avoid conflict over the dps_mailing row representing the mailing.)

  3. When the batch is complete, it merges the counts for the batch into the entry in the dps_mailing table that represents the parent mailing. Once again, it uses a lock to prevent concurrent updates.

  4. Changes the status in the dps_mail_batch entry to “complete.”

  5. Checks for another job.

Copyright © 1997, 2012 Oracle and/or its affiliates. All rights reserved.

Legal Notices