HandleSpecialURL, sessions and threads

Sorry if this is a re-hash of old topics but I haven’t been able to figure this out from the docs or in the forums.

I’m starting a new project which requires a web app whose sole purpose is to provide webservices for desktop client apps. I’ve got the following questions:

  1. Since each “service function” is going to be routed thru the HandleSpecialURL event:
    A) Does the web app automatically spawn a new thread each time this event is raised?
    B) If no automatic thread is raised, can I create my own threads from within this event where the real work will be done?
    C) OR can I create Session objects instead of threads to do the work?
  2. I’m going to use PostgreSQL as the DB - does anyone see a problem with having the App open and maintain the DB connection and pass a reference to this connection to the session or thread that does the work?
  3. Potentially there can be hundreds/thousands of simultaneous requests against this webservice - are there any scalability issues I should be aware of?
  4. I’m thinking this needs to be deployed as CGI - thoughts?

Sorry for what may seem like beginner questions. I’ve done plenty of apps like this with .NET, VB and IIS but this is a first for me with Xojo.

I don’t know the answer to A. You could test this easily though. Build a small app with a special handler and see if it’s running on the main thread. Or log the id of the thread and see if they’re all different.

As for the rest… The general rule on databases is “one connection per Session”. You can’t create an actual “Session” to manage your special calls, but you could create an APISession class (no super) that handles authentication and passes back a sessionId cookie or parameter so further calls can associate with the right APISession. Each APISession (a logical “api session”) would maintain its own connection to your database, consistent with the general rule.

And this is definitely not beginner stuff :-).

Hey Michael. We are developing a product to assist with this exact use case. If you have any interest in testing it and providing feedback then email me phillip@1701software.com.

In regards to your questions each hit is threaded. You cannot programmatically create sessions as they are deeply integrated with the javascript framework running client side. For your use case you don’t really need sessions however. It sounds like you just want Xojo to thread multiple HTTP connections which HandleSpecialURL does quite nicely. If you aren’t going to put a typical WE front end on this then it might make more sense to use a more bare bones HTTP server as you would have a tad more control.

By barebones I mean something like https://code.google.com/p/realbasic-httpserver/

I was told by one of the Xojo engineers that a new thread is created for each event. I do NOT know if it sticks around for a bit to see if there are any additional requests from the same remote user or not. I failed to ask that question at the time. :slight_smile:

This has all been VERY useful information. Thanks everyone!

Yes, interesting topic, it deserves to be developed :slight_smile:

@Bob Keeney : Threads do not “hang around” waiting for more connections from the same client.

Thanks for the clarification! I didn’t know if there was a timeout or not built in.

A session does die off eventually… So there has to be some internal clock somewhere that says “if javascript framework has not reported in by X time then remove all references to session.”

This would be completely behind the scenes and not related to the helper Timeout/TimedOut methods Greg mentioned.

Yeah, I meant I didn’t know if there was a specific timeout for the threads created via the Handle Special URL. I know about the regular session timeout.

Parts A and C have obviously been answered. You can create your own threads as well (B). But keep in mind that Xojo is cooperatively threaded. Only one thread is actually running at a time (i.e. threads do not take advantage of multiple cores).

[quote=44066:@Michael Bierly]
2) I’m going to use PostgreSQL as the DB - does anyone see a problem with having the App open and maintain the DB connection and pass a reference to this connection to the session or thread that does the work?[/quote]

As Brad said, one DB connection per session is a good rule thumb. A more precise version might be one per thread if you’re creating your own threads in addition to the sessions.

If you mean there can be hundreds to thousands of “in flight” requests at any given moment, or hundreds to thousands of hits per second, then I imagine you will need to load balance across multiple WE apps, possibly running on multiple servers. Depending on the database work the same may be true of Postgres. If your requests have to be coordinated in any fashion at the Xojo level then you want to think about this and design for it from day one. This is much more challenging the moment you have to scale beyond one running app.

That will introduce more overhead and latency.