Global requests.Session object drawbacks

Question

I recently found global request.Session() declaration. E.g:

# one of many files
import requests

g_session = requests.Session()

def some_foo():
    return g_session.post('https://example.com', data={'key': 'value'}

# rest of the code

From docs:

The Session object allows you to persist certain parameters across requests. It also persists cookies across all requests made from the Session instance, and will use urllib3’s connection pooling. So if you’re making several requests to the same host, the underlying TCP connection will be reused, which can result in a significant performance increase (see HTTP persistent connection).

So as i understand:

the benefits are no need to open new connection, and it can be reused

the downsides are supporting the same connection and keeping memory occupied

Is there anything else?

I've never seen such global declaration. Most of the times sessions are used in context manager way, or reuse object in same function/block code, but not globally.

_{Possible relevant info: it's part of django application.}

it keeps cookies between requests - so you don't have to copy them - ie. login cookies. You can set headers in session and all requests will use them - ie. `user-agent`. Frankly, I never used session in context manager, I use it only in this way. — furas, Aug 05 '19 at 17:46
How is supporting the same session a downside...? There's no continuous connection, it just preserves state, like cookies, just like furas mentioned. "Occupied memory" isn't that either, if it really was such a big deal, you wouldn't be using a language like Python to begin with. — , Aug 05 '19 at 17:52

score 1 · Answer 1 · answered Mar 12 '21 at 23:01

One drawback is that it is unclear whether Session is thread-safe, since the requests documentation does not mention it. A thread from 2013 suggests that it is not: Is the Session object from Python's Requests library thread safe? but it links an Urllib3 issue that has been resolved and closed: PoolManager is not thread-safe

You could make your session thread-local, but if you are accessing your Session from worker threads (e.g. in a HTTP server like Flask with uwsgi), you'll could end up with worker_threads*requests_pool_size connections, which seems excessive.

Global requests.Session object drawbacks

1 Answers1