PDF SDK based Multi-Applications
Building a multi-threaded PDF Application with easyPDF SDK is actually rather simple. Our PDF SDK does not handle this directly, your application will need to be responsible for multi-threading the PDF SDK. You will need to create the PDF SDK objects inside their own unique threads, process the operation you want to process, and then release the objects once done. So long as the objects remain in their own unique threads they will work without interfering with each other. The PrintJob.PrintOut() methods are all thread safe.
However certain aspects of the PDF SDK are not thread safe. In particular, calls to the .Save() methods, such as PrinterSetting.Save() are not thread safe. This is an unfortunate limitation of using a Virtual Printer to process the documents of the PDF SDK. Printers can only have one active setting for their Paper Size, or their Paper Orientation, because Printers can only actually Print one PDF document at a time due to physical limitations. Our PDF SDK's Printer may not have such a physical limitation, however the Printer Framework built into Windows assumes that it does and treats it accordingly.
If you call the PrinterSetting.Save() method it overwrites the Printer's settings for that User Account. As such if these settings are changed during an ongoing conversion it can cause issues. In the best case scenario the formatting between two different pages will be different, in the worst case scenario it can cause Memory Access Violations that kill the entire conversion process.
If you are printing on a Desktop Machine, running one conversion at a time, this isn't an issue. You can change the settings to suit each individual conversion. Even if you have multiple users, such as a Terminal Server environment, so long as each is logged on as their own user running a desktop application they can all change the settings as they please. However in a Server environment with the Loader, this will not work because the Loader must run through a Specific User Account, and thus any changes to the PrinterSettings will happen in that single User Account.
As such if you want to print from a Server you should determine the optimum settings and apply them once using the .Save() methods for the appropriate objects, at which point those settings become the default for all subsequent jobs on that machine. If you need to be able to change the settings the best solution is to run multiple parallel servers, each with their own settings, and sort the jobs appropriately.
PDF SDK Com object based multi-threaded Applications
BCL’s PDF SDK COM objects are not capable of working in a multi-threaded apartment (MTA). They must be run in a single-threaded apartment (STA). In .NET Framework 4 the default setting for a thread is MTA. None of our PDF COM objects work in a multi-threaded apartment, so you must manually set the thread into STA. If a COM object is MTA, it means multiple threads can interact with it. Our PDF COM objects are STA, which means strictly single-threaded. You can run multiple instances of our PDF COM objects in parallel, but multiple threads can't share the same PDF COM object. Each PDF COM object must be isolated in a single-threaded apartment.
This apartment concept (MTA vs. STA) is an aspect of COM Objects. When you create a new Thread in .NET, you need to choose if it's an STA or an MTA. This is only important if you plan on using PDF COM objects. An MTA thread makes it possible to share the same COM object between multiple threads. That's fundamentally different than STA. MTA and STA work totally differently. Since easyConverter and easyPDF are all STA, the thread must be STA.
This doesn't mean you can't run multiple threads with easyPDF. You can, but only in an STA apartment. This is hugely counter-intuitive, because it's called a "single-threaded apartment", but it doesn't actually mean you are restricted to a single thread. However, if you try to run an STA COM object like easyPDF in an MTA apartment, the system will serialize the function calls. It won't run in multiple threads. An STA COM object only works in multiple threads if it's run in an STA thread.
So both MTA and STA COM objects are capable of multi-threading, but they work totally differently. The bottom line is that you must run easyPDF from an STA apartment. And the customer can fix this in a single line of code.