Application Object and Databases in Xojo Web Services

Targets Web
1

So I have reviewed a lot of tutorials both written and on video concerning using databases connections in web services developed using Xojo Web. Most of these tutorials seem to be basic starter apps focused on teaching how to create a web service in Xojo, and I am not sure if the architecture shown is the best method for developing scalable web services in Xojo.

Each of these tutorials seem to put database connection code in the Application object. I believe many open a single connection on the open event and close the connection on the close event. Since the Application object is shared by each connection - doesn’t this mean that every connection would be sharing a single database connection? While one client used the connection, wouldn’t additional clients need to wait for the connection to be released?

Even though web services are stateless and do not have session data held between connections, it seems to me that the database connections should be acquired on each session initiation, perhaps from a pool of connections in the application object.

I might not have a good grasp on how the Xojo web framework works. I am hoping someone can give me a pointer in how this should be handled in a real world web service and if concurrent connections can execute code in the application object at the same time.

Thanks.

2

Database connection is per session, so each has its own error state and its own transaction state.

For web service you may pool and reuse connections. But make sure it is always one connection per thread.

3

So this code should be put in the session object or is putting database connection code in the application object, like I have seen in tutorials, still valid for a web service? A lot of tutorials for web services only had code in the application object for the whole service.

4

For a web service, there is no session. All HandleURL code is run sequentially on a separate thread from the sessions. A single connection is sufficient.

1 Like
5

Ok, thank you. In other languages I have worked with, each connection began a session. In a web service no data would be kept in the session and no session cookie or view state was set. So perhaps that is where I was confused.

So the tutorials showing all of the code for web services taking place in the application object is the most efficient and recommended way in Xojo, I take it.

6

And I don’t mean to be dense - but does this mean that long running processes in the HandleURL code would block additional connections to the web service?

7

Yes. It would also block other sessions, since everything is run on a single core with cooperative threading.

1 Like
8

Thank you so much Tim. That really explains a lot. In Python Flask apps, if using Gunicorn, I would start multiple worker processes based on the number of available cores, and I am assuming the Xojo web services would be deployed in the same manner, since it seems to work in a very similar way.

9

Many people have reported success running multiple instances of their app (on different ports) with a load balancer like nginx in front of them.