Westwind Web Connection server on LAN: can SPT (MS SQL) work ? 4

[Steve Yu]

Hello colleagues,
We have a working Web Connection server on a LAN (internal web) that employs .dbf and .idx only currently.
Is it possible to add SPT coding to access the MS SQL tables that are on the same LAN concurrently ?
This is our effort to expand exiting desktop applications to include access from the web.
Help appreciated.

Steve Yu

 

[Chris Miller]

Our version of the WWWC server is very heavily modified

It would be importsant to know what you have overridden from the normal WC processing to finally answer for example, whether SET PROCEDURE would only need to be done once.

I don't think so based on a simple assumption: don't think Rick Strahl or other West Wind WC developers would implement something that could only process one request at a time. Parallel processing combined with a state that's kept for all requests without reinstating that state as it's done with a session cookie in HTTP that's sent in with every request and is therefore not a server side state but has to be coming from the client everytime.

The only chance for a state that's not just a virtual state that's indeed reinstated with every request is WC running in a multithreaded DLL. Then multiple instances of the wwServer class that's always the entry point of all requests for WC itself, which then routes it to your wwProcess based class Process method - multiple wwServer instances of the same mtdll would run in the same process in multiple threads. I wonder if they would all route the request to the same wwProcess instance, though or also multple instances of your class in the respective thread. All running in the same process would be able to see the same PRGS/FXPS of an initial SET PROCEDURE, see the same PUBLIC variables, could reuse the same SQL Server connection handle and even see the same properties even if multiple wwServer objects provide the parallelism but all route to the same object instance of your class derived from wwProcess.

The other way of parallel processing would be by parallel processes, then you don't have any state in common in all requests. You'd easily be able to find out experimenting with this, I'd just recommend you try more than just two successive requests, as there can always be the case you only hit the same process or object instance by chance. So a good experiment would do requests in fast succession, ideally asynchorincally in parallel from multiple clients, even though that's not reflecting the final real world scenario, later.

Unless you know by digging into the architecture of WC and your "heavily modified" version, you have to do this "nonrealistic" experiment to ensure. It's not províng, but making very plausible, when you always can reuse the same connection handle towards SQL Server, that it's all runnning in one process server side. I'd say that's not making the best usage of the web server, but that's not your concern, that's a WC concern, if any.

You don't profit very much of it, because being able to reuse the connection handle still doesn't make the overall sql processing much faster, to get the fastest processing you'd still need to have WC on the same server as the MSSQL server. I also don't know what experience you have with the time necessary for SQLCONNECT or SQLSTRINGCONNECT in your company. If that's so high you're making it a topic of being able to reuse a connection handle, there's something to investigate in your network and server architecture, it should not take long to make a connection.

 

[Chris Miller]

Okay, I think I found it. The discussion about multithreading vs multiprocessing already was a topic in another thread here, in which I linked to a Web Connection web blog article of Rick Strahl:

Visual FoxPro and Multi-Threading

This quote is telling how WC essentialy does prallelism:

There other alternatives in how to run EXE servers – like running a pool manager of instances so that instances are loaded and then cached rather than having to be restarted each time. I use this approach in West Wind Web Connection, and by removing the overhead of loading a VFP instance each time and keeping VFP’s running state active, raw request throughput performance actually rivals that of DLL server with this approach. However, this sort of thing only works if you can control actual activation as part of the application you are building (as I do in Web Connection)

This is saying Web Connection uses a ppol manager that has multiple WC processes running, then you can't rely on having any state available in requests, a secondary request can be handled in another process than the first and thus you can't reuse anything, not even a connection handle.

 

[Steve Yu]

Okay, I think I found it. The discussion about multithreading vs multiprocessing already was a topic in another thread here, in which I linked to a Web Connection web blog article of Rick Strahl:

Visual FoxPro and Multi-Threading

This quote is telling how WC essentialy does prallelism:

This is saying Web Connection uses a ppol manager that has multiple WC processes running, then you can't rely on having any state available in requests, a secondary request can be handled in another process than the first and thus you can't reuse anything, not even a connection handle.

We do have a public facing WWWC server in the cloud now that's been working many years for our vendors and customers (same structure as the proposed new project which will be an internal web only).
As to multi-thread, without much knowledge of how WWWC works as an .exe or .dll, we simply fire up multiple copies of the .fxp version and let it fly. As I mentioned before, I do see some coding that we added that seem to be shared by sessions. I'm now experimenting to see how SPT will fare within this setup.