Support Center

Welcome back, guest

Register or login below.

Knowledgebase

Feedback

12
I agree
Gathering Feedback

Support for concurrent mail merging

Current GemBox.Document class is not thread-safe. If you start mail merging in multiple threads it will probably end up with an error.

Since merging of huge documents could be time consuming and since most of the processors nowadays contain two or more cores it would be nice if the merging could utilize the full power of the CPU. That means to
- split the merge into several threads, every working with its own document model
- run them in parallel
- wait till all threads are complete
- join all document models into the final one

However, this is not possible now. At least not when you have custom Document.MailMerge.FieldMerging event.

3 Comments

  • Mail merge in large documents can be optimized so that a small region of a document (instead of an entire document) is duplicated and filled with data for each record in the data source. For an example visit the following link:
    http://www.gemboxsoftware.com/SampleExplorer/Document/MailMerge/MergeRanges

    Running mail merge in parallel would require following steps:
    1. Partitioning of the original data source for each thread.
    2. Loading or cloning original template document in each thread.
    3. Executing mail merge on the clone of the original template document with the partition of the original data source in each thread.
    4. Wait for all threads to finish and merge resultant documents of each thread into one resultant document.

    As an example (with using FieldMerging event), see the following:
    "www.gemboxsoftware.com/document/downloads/ConcurrentMailMergeTest.zip"<br />
    Opposed to regular mail merge, concurrent mail merge has a lot of redundant operations required to enable parallelism without blocking. These operations are partitioning the data source, cloning template document and merging resultant documents. These extra operations make concurrent mail merge more inefficient than the regular mail merge.

    Conclusion is that mail merge in GemBox.Document is naturally a sequential operation because housekeeping operations required to achieve parallelism outweigh the actual parallel execution.
  • ( Sorry for a long time of my response ).

    In general I could agree with your conclusion for simple mail merge. But I can't agree for our case. In our company we are using mail merging for exporting a very complex documents for construction business area (like tunneling) where several hundreds of pages are being printed. The data source is hierarchically structured and allows fast partitioning by calling GetChildRows(). Overhead of cloning original template and merging results is acceptable for us because sequential operation is anyway taking 2-3 minutes on a very fast hardware (i7, 16GB). And our customers don't have such a good machines.

    BTW: The link to your "concurrent mail merge" is not working anymore. Could you, please, fix it?

    Since you prepared an example does it mean the feature had been implemented?
  • Hi,

    First no, this feature has not been implemented jet.
    Second, can you try that link again, unfortunately it seems our CRM has some difficulties with formatting that comment.
    Note that the text of that link is correct and please make sure that the link to which it's pointing to must be the same as the text.

    Regards,
    Mario