HandleURL Session Specific

Targets Web
1

I’m designing a Web Service (Web App) that will be getting passed a list of values from a number of sensors. The sensors will be using a URLConnection to pass in a JSON list of name-values at periodic times, which the Web Service will use to update a database.

My question is this, when creating a Web Service does each request spawn a new Session, or does each discrete call the the Web Service (POST / GET) fall out of scope as soon as the WebResponse is returned? And, if multiple clients all call the Web Service simultaneously does the App itself spawn multiple threads to handle each request?

2

Each call to HandleURL is distinct and knows nothing about any other calls. The web service handles each call in a separate thread. (A separate Xojo thread, which are cooperative, so they share the same processor core. They don’t take advantage of multi-core processors.)

3

Sessions are not created for calls to HandleUrl, but you could create your own system for that. Many APIs require a login for security and issue time-limited tokens (after which the client must send credentials again to get a new token). You could use this token as a key in a dictionary which holds persistent data.

4

Tim/Greg, thanks! I’m still trying to get clear on how to keep code execution from overlapping between several simultaneous calls to this API. For instance, if the OPEN event of the web app (API) is used to open a database connection, which is then used by other methods in the App object, and a 2nd HandleURL call is received by the App, is a 2nd instance of the App itself created? In other words if I create local constants and other variables at the App-level, are these uniqued to each thread spawned by HandleURL call? (or do the vars become suddenly shared across all threads?)

5

You should open database connections in the HandleUrl event and close them when you are done. Allowing all api calls to use the same connection is just asking for trouble.

6

This is why I suggested the token route. Make a class to hold the api persistent properties and create an instance when a client first logs in. Then you store the instance in a dictionary based on the token. Any time a client comes back with the same token, you retrieve the class from the dictionary.

1 Like
7

And just for clarification, when is the call to HandleURL officially ‘done’? Is it when the end of that method is reached?

I’m returning the results of the API ‘call’ via Response.Write(my_response_string). Is there an Event I should be monitoring that knows when the Response has finished transmitting?

8

When HandleUrl is done, the framework transmits the response back to the browser.

9

I’ve never used HandleURL (yet), so I should first make sure I’m using it as intended. Perhaps there’s another http method I should be using?

From a high level my architecture is designed so that all these external sensors “call in” using the HandleURL like this:

MyWebAPI-App.URLConnection.Send(“GET”, “http://10.0.0.131:8080/Sensor_ReportPVs?PV1=“123”?PV2="456"”)

…I was intending to put a token in the list of passed-in parameters and can use that to associate the data to a proper SQL update statement.

The client (sensor) will use the values returned in the api’s response to update it’s own local logic.

Final questions for this morning then…

Q: Is the combination of a client-app using ‘URLConnection’ and the api-app using ‘HandleURL’ the best logical combination for these types of frequent client-server updates?

10

…and thanks for all your time on this Greg! Once I nail down the overarching design then the real work begins. I’m just doing my best to vet the best overall solution before invest a ton of coding time only to uncover a better approach. Again thanks to everyone for helping my efforts to vet this approach. :slight_smile:

11

I have a problem in that I pass the HandleURL to a New Class that looks up the database and returns a value, but I use SQLDatabaseMBS’

rs = tempSQLPreparedStatementMBS.SelectSQLMT

as this allows another thread to run, and so I get another HandleURL accepted before the first one is finished! I have not does enough testing to see if this is a problem, but I suspect it is.

12

Yes.

App properties are shared across all connections. So as Greg says, use variables local to the HandleURL event.

Yes. When the method returns, the response is sent and everything is done.

There is no additional event. Your response is sent back when the HandleURL method finishes and that’s it.

13

Here’s a simple sample of what I was suggesting: API Sample.xojo_project

1 Like
14

Greg, Tim, and others - thanks for helping me get clear on the scope of these functions. The sample code is a great blueprint! Best to all and thanks again.

15

You need to be alert on the data transfer rate as well. As the process of opening / updating / closing the the database with new data value might take sometimes. For automation purposes / low - frequency telemetry / SCADA application should be fine. For real time control and data acquisition you have to evaluate whether this approach is suitable or not. If the data are transferred across multiple network, you should also be alert on the visibility of the data transferred as well.
However, data acquisition over the web via GET / POST through Xojo’s HandleURL is one of the most flexible approach available. Higher data transmission can be achieve using WebSocket but that is not available yet for Xojo Web at this stage.