4đź‘Ť
Keeping a transaction open has pros and cons.
On the plus side, every transaction has an overhead cost. If you can do a couple of related things in one transaction, you normally win performance.
However, you acquire locks on rows or whole tables along the way (especially with any kind of write operation). These are automatically released at the end of the transaction. If other processes might wait for the same resources, it is a very bad idea to call external processes while the transaction stays open.
Maybe you can do the call to the 3rd party API before you acquire any locks, and do all queries in swift succession afterwards?
Read about checking locks in the Postgres Wiki.
2đź‘Ť
While not exact answer, I can’t recommend this presentation highly enough.
“PostgreSQL When It’s Not Your Job” at DjangoCon US
It is from this year’s DjangoCon, so there should be a video also, hopefully soon.
Plus check out authors blog, it’s a golden mine of useful information on Postgres as a whole and django in particular. You’ll find interesting info about transaction handling there.
- [Django]-How to set User in request.user in Django using MongoDB
- [Django]-Two or More Django Projects in Same Droplet via Subdomain
- [Django]-How to do Delete confirmation for a table data with bootstrap Modal in Django?
- [Django]-Django mocks not working as expected