Hello prisma team! Have a question with respect to...
# orm-help
n
Hello prisma team! Have a question with respect to prisma connections. How does prisma fetch a connection from connection pool? Context - I am using Postgres as DB and turned logging on. So in the following code snippet, prisma is fetching two connections from pool.
Copy code
// Node js
// Fetched a connection from pool. --> (1)
const firstQuery = await prisma.model.find();
// Fetched a connection from pool. --> (2)
const secondQuery = await prisma.model.find();
So
1
and
2
statements are logged while calling these queries. Can you explain why second statement is logged? Prisma should use the same connection (connection used for performing first query), right?
j
Does it indeed use two different connections?
The log output might just indicate that it asks the pool for a connection - which might very well be the same one.
n
So how I can be sure about this like whether it is opening two different connections or same connections? And if yes where I have to look i.e in Prisma client or in DB?
j
I would look at the database log to see if multiple connections are opened or not
Prisma might lie to you anyway - only the database really knows and can tell
n
Ok sure, I will then log enable db logs, and check, thanks for clearing out this!
👍 1
Hey @janpio can you please explain how the pool connection works? Over here, this connection pool is utilised by Prisma client right? So in the third point
When a query comes in, the query engine reserves a connection from the pool to process query.
So after the query is executed, does prisma release this connection and again put that connection into the pool? Or it picks a new connection?
j
Prisma is the connection pool.
Prisma Client starts with 0 connections.
When you run a query, it creates 1 connection and uses that to execute that query.
When it is done, the conection is kept open but put in the pool.
Next query, grabs a connection from the pool instead of opening a second one.
If none is available (as query still running or still being moved around), it opens a second one.
Afterwards also puts that in the connection pool and keeps it open.
It will add new connections until the connection pool limits is reached.
Afterwards it will wait a bit to get one from the pool, or timeout with an error message that the pool is exhausted.
Does that explain it?
n
Hey yes that explains a lot, is there a way we can log these details? Reason - we want to debug an issue on our production app. We have turned on logging, but we weren't able to reproduce the bug consistently. Bug is basically we are running two queries one after another, if both the queries use same connection then its working correctly but if the latter query use another connection we will get an error.
j
Why is that? Does the query rely on the previous one setting some state in the connection?
n
So with first query we are creating
temporary_table
, with second we are inserting into the
temporary_table
. Temporary tables in postgres remains per session (don't know how sessions are managed in Prisma i.e if session can have multiple connections or not). So kind of second state is dependent on first state.
j
If so, Prisma generally gives no guarantees on the connections. Even if you get the same one, it could actually be a load balancer or pooler (e.g. PgBouncer) that uses two different database connections
So you have to wrap that into a transaction for sure.
n
Yeah wrapping in a transaction makes sense. https://prisma.slack.com/archives/CA491RJH0/p1623081093137000?thread_ts=1622831239.062200&cid=CA491RJH0 So while picking a connection does it have any id or something for differentiating between the connections?
j
No, we are not exposing that in the logging yet as this is an internal implementation detail.
Might be worth an issue - but the answer will also be to use a transaction to get a guarantee.
n
Thank you so much for this detailed explanation, will try using transactions for the queries.
👍 1