Concurrent updates that don't interfere with each other

Problem

I need to get the first entry of a list of oneTimeKeys for a specific user and update it to be connected to the user that “claims” it.

What I did until now:

const oneTimeKeyResult = await prisma.oneTimeKey.findMany({ // could be findFirst
  where: {
    user: { id: userId },
    claimedByUserId: { equals: null },
  },
  take: 1,
});
const oneTimeKey = await prisma.oneTimeKey.update({
  where: { id: oneTimeKeyResult[0].id },
  data: {
    claimedByUser: { connect: { id: currentUser.id } },
  },
});

The problem here is that if two or more users try to claim the same oneTimeKey at the same time they can can and it actually happens sometimes in production.

Suggested solution

Running the find and update in a transaction would be nice, but this is not supported currently.

Alternatives

Since I’m running on Postgres (if I understand correctly) I could do a executeRaw with an update using FOR UPDATE SKIP LOCKED

https://stackoverflow.com/a/56441907/837709 https://dba.stackexchange.com/questions/69471/postgres-update-limit-1

[nikolasburk]

Then I though updateMany would help, but it doesn’t allow to update the relationship:

const oneTimeKey = await prisma.oneTimeKey.updateMany({
  where: {
    id: oneTimeKeyResult[0].id,
    claimedByUserId: { equals: null },
  },
  data: {
    claimedByUser: { connect: { id: currentUser.id } }, // THIS IS NOT ALLOWED
  },
});

Ah sorry, this is indeed not possible. However, with the new preview feature uncheckedScalarInput which allows to set foreign keys directly this would work:

await prisma.post.updateMany({
  where: {
    id: oneTimeKeyResult[0].id,
    claimedByUserId: { equals: null }, 
  },
  data: {
    claimedByUserId: currentUser.id // this is possible since v2.11.0
  }
})

To use this feature, you need to set the uncheckedScalarInput on the Prisma Client generator:

generator client {
  provider = "prisma-client-js"
  previewFeatures = ["uncheckedScalarInputs"]
}

Don’t forget to run npx prisma generate afterwards (sometimes I also need to rm -rf node_modules for the latest version to show up).

[nikgraf]

@nikolasburk ahh nice, makes a lot of sense.

Just for the record in the end I went for a raw query since the queries above would have required me to write my own retry logic. If I understand correctly using FOR UPDATE SKIP LOCKED for Postgres it’s not necessary.

This post explains how queues with Postgres are possible using FOR UPDATE SKIP LOCKED https://www.2ndquadrant.com/en/blog/what-is-select-skip-locked-for-in-postgresql-9-5/