I am having problems with the Multi-Threading with Aspose.Cells. It appears to only affect the Worksheet.Copy and the Worksheet.Cells.CopyRow functions. It also only happens on servers with more than one processor.
To get around this issue, I am having to manually lock this process from multiple threads executing the commands. (See code below for workaround)
Can this be fixed? *********************** lock (objLock) { newWorkSheet.Copy(wstemplate); }
Aspose.Cells supports multi-threading. You can call it's functions in several threads concurrently. However, you can manipulate a single Workbook object in several threads concurrently because there are global data in a Workbook object which cannot be process concurrently.
However, the object that I am copying from (the template worksheet) is the same for all the threads. Is this causing the issue. Do I have to create unique instances of my template worksheets per thread in order to copy worksheets or copy rows?
This is not a good solution, only a work around do to the fact that your product cannot handle multiple threads copying information from one worksheet to another.
The fact that I am only trying to read information and not modifing it, I do not see why this is a problem and could not be fixed.
This solution will also cause my applications to consume a lot more memory because I am force to create many instances (in my situation over 200) of the exact same worksheet because your application is not capable of supporting multiple threads reading data from a single worksheet.
Until you have a better solution, I will be forced to work around this bug.
As I mentioned at <A href="</A> , this is not a bug. </P>
<P>If you want to save memory, please lock the Copy method as your solution. Or you can create different instances if your template file is not large.</P>
An object like that should never be assumed to be thread-safe (in fact, I would say that if it had been written to work thread-safe it would be broken, as normally you wouldn't be using several threads on a single workbook and it would have caused a lot of unnecessary overhead).