Closed dsuch closed 5 years ago
Hi @dsuch, I think SQLAlchemy's standard engine / connection pool hands out a connection to each thread that requests one, no matter which thread actually created the engine / pool. So I think you should be okay. In the docs it says:
A single Engine manages many individual DBAPI connections on behalf of the process and is intended to be called upon in a concurrent fashion.
http://docs.sqlalchemy.org/en/latest/core/connections.html#basic-usage
I haven't heard anything further on this, so I think I'll close it. Please re-open if it's still a problem.
Hello,
I'd like to update pg8000 version used in Zato from 1.10.2 to 1.11.0 but what caught my attention in changelog is this entry:
""" Connections and cursors are no longer threadsafe. So to be clear, neither connections or cursors should be shared between threads. One thread per connection is mandatory now. """
Zato is based on gunicorn and gevent, which means that each incoming request (e.g. HTTP, AMQP, ZeroMQ etc.) is handled in its own greenlet, which is basically a thread from an external library's perspective, such as from pg8000.
If connections and cursors are not thread-safe, I read it that I cannot have an SQLAlchemy-based connection pool built in one thread (greenlet) that all the incoming requests (greenlets/threads) use.
Instead, I would need to open a new physical TCP-level connection in each greenlet/thread, and since we can easily handle thousands of req/s, it would mean thousands of new connections to DB each second, if I interpret the changelog correctly.
Could you please confirm I my understanding is correct? If so, how will pg8000 work with SQLAlchemy now, or indeed with any application that uses connection pools built in separate threads/greenlets?
Regards.