views:

192

answers:

2

I have a "ActiveX library" project created with Delphi 2007. The library interface return XML data based on input values. This is then used by a PHP script that displays the data on a web page. This works great!

The problem is that i can only run one instance of the dll process on the server. However, for security reasons, each of my customer should be able to access their own process of the dll (because the dll is always connected to only one database).

Also, because of the way the delphi code is built, it doesn't support multiple threads. (It's a 100 000+ lines project using lots of singleton classes)

Is there a way of starting several instances of the same dll? Is there a better way of transferring XML data from delphi to PHP?

Sorry for the longish question, any help is appreciated

(ps. I know the delphi code should be refactored, but this would mean 6 months of "circular reference" -hell :)

A: 

the only way i see to solve this is to put some kind of middleware between the delphi part and the php part , which will collect the requests, put them in a queue and process them one by one using the delphi code. maybe you could refactor the php part to show the data asynchronously - that way the php process could return quickly and show some kind of "Loading.. please wait" message to the user, and after that, by ajax keep trying to retrieve the data until it's available from the middleware (for instance the php script could put the request in a database table together with the session_id, and the middleware part could process each request from that table one by one, writing the retrieved data back to the table. meanwhile, the ajax request could keep querying the table until the data is available).

matei
+1  A: 

You can simulate a CGI, or even use CGI. Basically you need a server that watches for incoming requests and makes a session for each new user. Then each session starts a new process that loads the DLL. The process is just a sandbox for the DLL in question.

So you have the following parts:

  1. A server (HTTP, TPC, SOAP whatever...)
  2. A client sandbox process
  3. Your DLL

A client process is just a dummy process that its sole purpose is to load the DLL and acts as communication bridge between DLL and server. Use IPC (inter process communication) to delegate communication between server (sessions) and the sandboxed processes holding the DLL. This way you have isolated processes for each customer and you gain in system stability. Failure of one DLL is not the failure of whole system.

Many systems nowdays work this way:

  1. CGI
  2. Google Chrome
  3. Latest IIS and Apache ISAPI ...

Just be carefull to have a session limit, otherwise to many processes could be spawned, taking the host OS down. For reference about process limits read the great blog post by Mark Russinovich:

Pushing the Limits of Windows: Processes and Threads

Runner