Is it possible to introduce transactions for HTTP only clients? #1583
Replies: 3 comments
-
It's an interesting idea. Unfortunately, Postgres spawns a process per each connection and an open transaction would preclude that connection from being reused by requests from other clients which would lead to either very bad latency (clients waiting for the transaction timeout to expire), or bad resource utilization (tons of Postgres processes waiting for the transaction timeout to expire). These concerns aren't specific to HTTP, really. If you have a distributed system with lots of simultaneous requests you want to minimize the number of transactions that span multiple requests to the database. Prefer to use the power of EdgeQL to pack logic into atomic queries instead and use things like server-side functions and computable properties. |
Beta Was this translation helpful? Give feedback.
-
Yeah, we are thinking about adding support for tunneling binary protocol over websockets. That would allow long running transactions via HTTP. That will be disabled by default though, because open transactions consume significant server resources and so this approach does not scale well. It might be a good option for a controlled environment though.
Interesting. EdgeDB uses PostgreSQL as a backend, so as I said before, open long-running transactions have a high cost.
Yeah, we'll look into implementing cancellation policies like this. |
Beta Was this translation helpful? Give feedback.
-
Thanks @1st1 @elprans for the answers. That clarifies the doubts. |
Beta Was this translation helpful? Give feedback.
-
While there is no clean/direct way to introduce transactions with stateless HTTP protocol, but if this can be somehow be pulled up, it really opens interesting architectural possibilities for web applications - For example isolated database multi-tenancy with shared application instance! - app won't really have to maintain the connection anymore. Another use case is serving as a back-end data store for server-less infrastructure.
I have used this model with Dgraph and the team seems to have really pulled it off well. May be we can possibly explore using some time-based rollback on the stateless HTTP where expected time/duration would be specified at the time of commencement of transaction and returning a unique id to use it in subsequent queries and then eventually completing the transaction. After the duration, transaction would be simply aborted.
Beta Was this translation helpful? Give feedback.
All reactions