Question

I am developing web app on flask, python, sqlalchemy and postgresql.
My question is here regarding concurrency handling in this app.

How I wrote the app :

I take the example of adding user in database. I post the form and a view is called. I process all the form data and then call add_user(*arg) which uses sqlalchemy code to insert user in database and returns on successful execution and I return the response from the view.

What I assumed:

Ok now I assumed that my web server (which I have not decided yet) will either spawn a thread or a process if two users are trying to signup at the same time and will handle all the concurreny requirements.

1. Do i need to write threaded code here? By threaded code I mean that before writing I acquire a lock and after write release it.
2. I am pretty new to web development and multithreading/multiprocessing programing and would like some guidance on how write web app which can handle concurrency well.
3. Writing concurrency handling from start is right or this thought should come when a large number of concurrent users are using the webapp. Even If it should be done later I would like some pointers about it.

Basically I have no idea about concurrency part of webapp development. If you can point to resources from where I can learn more about it would be really helpful.

Answer 1

Flask will execute each request in a separate thread or even in separate processes. The number of threads and processes to spawn is determined by the WSGI server (for example, Apache with mod_wsgi).

If you use SQLAlchemy ScopedSessions, the session is perfectly thread-safe. You must not share ORM-controlled objects across threads (but in the large majority of cases, you won’t let your objects live longer than a request anyway so this is usually not a concern).

In other words, as long as you don’t intend to share state between requests other than through the database or cookies, you don’t need to worry about concurrency issues. You don’t need to create a lock for writing to the database.

If you create your own long-lived objects within your application, which you most likely don’t need to do, and if those objects communicate or share state with request handling code, then you must take appropriate precautions to avoid synchronization issues (race conditions, deadlocks, use of libraries that are not thread-safe, etc.)