Unclear where to call prisma.disconnect()

[brandonweiss]

I read this section on managing connections in your docs and I found it a bit confusing.

To start, the important note is not very clear… I don’t understand what the scenario is in which the Prisma Client doesn‘t do the right thing. A better explanation and a code snippet showing the problem would be really helpful.

Additionally, the important note simultaneously says that the Prisma Client should just do the right thing but also says that sometimes it won’t. I think it should be one or the other. If the client can be made such that it always does the right thing, then great! If not, don’t even mention it, just clearly explain what someone has to do to protect themselves.

Which leads into the last problem… which is that I don’t know where to call prisma.disconnect(). Right now I’m just peppering disconnects after every query—that’s clearly not right.

I’m using Express, so… would the generally correct thing be to use a middleware to disconnect at the end of the request/response cycle?

import { PrismaClient } from "@prisma/client"
const prisma = new PrismaClient()

express.use(function(req, res, next) {
  res.on("finish", () => prisma.disconnect())

  next()
})

I took a look at the Prisma Client repo but because of the way it’s built I can’t tell if when I instantiate a new PrismaClient is it returning the same instance (a singleton) or am I getting a new instance? Rather, it’s unclear if calling prisma.disconnect() in this way would actually disconnect all connections, or just the connections that were specifically started with this instance of the client.

[schickling]

I've created an issue https://github.com/prisma/prisma-client-js/issues/540 which once implemented makes calling prisma.disconnect() optional.

[brandonweiss]

Awesome! ❤️

[timsuchanek]

Thanks for the question @brandonweiss! prisma/prisma#540 will not help with your situation, as it would only disconnect if Node would exit.

But as you have an Express server running, Node wouldn't even exit.

In your case, as the Express server is running, you can just skip the disconnect call for Prisma Client.

If the Node process exits for whatever reason (e.g. a crash), the client will also close the connection automatically.

[thisiszinger]

Just to clarify: for one-off uses of prisma database access outside of the instance passed to ctx, we should still call disconnect once done? Or will clients always auto-close their connections?

[nikolasburk]

@zingerj you don't to disconnect() in these cases but only right before your application terminates. No need to close the connections after one-off uses.

[thisiszinger]

But doesn't each instance of the client handle its own connection? Like if I generate a new instance during context creation to fetch the user, shouldn't I disconnect that instance once I'm done (or once it errors)? Or is that not necessary?

[nikolasburk]

We need to (and will) document this better.

But doesn't each instance of the client handle its own connection?

That's correct, every Prisma Client instance starts its own query engine process which in turn manages its own connection pool. (btw, we have some new docs on the query engine, the docs are still WIP so expect a few bugs, also the links are pretty much all broken and will be fixed soon).

Like if I generate a new instance during context creation to fetch the user, shouldn't I disconnect that instance once I'm done (or once it errors)?

If you create a new PrismaClient instance per incoming request you're right and you should disconnect. However, you probably want to attach an already existing instance of PrismaClient to the context so that you're only using a single instance in all your resolvers.

[mhwelander]

Now documented: https://www.prisma.io/docs/concepts/components/prisma-client/working-with-prismaclient/connection-management#calling-disconnect-explicitly