0

Currently, I am working with SAP Business One SDK. I took some project from another team. This project is a SOAP web service. It has been written in ASPX technology, anyway another team used standard DI API library. This is the main problem with this solution because it causes a lot of problems with memory leaks.

In source code after every operation when DI API is called I try to use Garbage Collector, but unfortunately, it is not enough.

The web service is hosted on IIS and I had to set an option that for some time restart it. I know it is not the best solution, but it works. Obviously, that way generates many problems.

I have a question about it. Does any reasonable solution exist? Or I will have to rewrite source code using DI Server?

I have read a lot about this, I found some articles on the Internet. Please do not put any links in comments, because I am quite sure that I have read them.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
a.dudek76
  • 11
  • 6
  • I have always put the DI connection in another process with a queue between them due to the issues you've found. – Daz Nov 12 '17 at 07:05
  • Could you give me some example of your solution? It's very interesting. Thanks in advance. – a.dudek76 Nov 12 '17 at 11:33
  • The simplest approach would be to build an XML of the update you want to make, drop that into a file/database table/message queue (or similar) and then have a console app or service feed off that and push the XML into the DI. Assuming your transactions are suitable for the LoadFromXML methods of the DI. Obviously your payload data and service could be something more sophisticated. – Daz Nov 12 '17 at 22:35

1 Answers1

1

Every time you use a DI API object you have to release it. Otherwise, it will stay in memory and it will cause the memory leak you mentioned.

The correct way to release them is to use ReleaseComObject. Remember that if the object is null you will get an exception so check it first.

if (oDocuments != null)
    System.Runtime.InteropServices.Marshal.ReleaseComObject(oDocuments);
Ander
  • 79
  • 3