Is there a way in Prisma to queue transaction calls in Mongo Prisma #orm-help

Is there a way in Prisma to queue transaction call...

Richard

09/18/2022, 8:18 AM

Is there a way in Prisma to queue transaction calls in Mongo? I have: - a

api/register

endpoint - which runs a multi-document transaction in my mongodb database (

updateMany

) The Issue I'm encountering: If two calls to that endpoint are made quickly, the latter one fails because the former's transaction in mongoDB isn't done yet. (see screenshot) (continues in thread)

✅ 1

Richard

09/18/2022, 8:18 AM

I'm wondering if prisma has a way to handle this scenario? Does it support some memoization that executes the database call only if the payload has changed? Here's the error

Copy code

Command failed (WriteConflict): WriteConflict error: this operation conflicted with another operation. Please retry your operation or multi-document transaction.)

Solution: • One way I can think of is to just run a

get

beforehand & compare the payload values to see if that execution is really necessary. Would like to know from more experienced developers how we I should handle this though.

Lars Ivar Igesund

09/18/2022, 8:27 AM

De-duplication of requests is not uncommon, but is probably something you'll place outside of prisma, and often together with caching. An example is the cache for the GraphQL-engine Mercurius (for Fastify). If the queries are dependent in other ways, they should presumably be held back at the client side?

Richard

09/18/2022, 8:43 AM

Thank you @Lars Ivar Igesund, that's good input. Re: caching That's interesting although I hoped I'd have to implement caching at a later stage. 😅 The API I'm working on is NestJS and I would have to understand their recommended way of caching. Thanks for this suggestion. Re: client-side Well, I don't always have control over the requests being issues. Imagine a user opening the same url in two tabs quickly and/or hitting refresh/back buttons in the browser quickly.

Lars Ivar Igesund

09/18/2022, 8:47 AM

Sure, but would those cause dependent queries? Wouldn't they just be duplicates? FWIW, the mongo driver has a thread pool and a queue to it, so it will handle quite a few concurrent requests (the exact numbers are configurable).

Lars Ivar Igesund

09/18/2022, 8:49 AM

Also, I'm still on Prisma 1, so not everything I know is likely to be relevant, but I think this is mostly a topic that is outside the scope of prisma. But I am currently in the process of finishing up caching (using express and Apollo rather than Fastify/Mercurius for annoying reasons), and also had to look at the configuration of the mongo driver.

Richard

09/18/2022, 8:51 AM

If they're duplicates, then caching is indeed the way to determine & respond. If they're not duplicates, then I'd expect the mongo queue to just go through

Richard

09/18/2022, 8:52 AM

However, in my case it's throwing this WriteConflict error, so I guess I have to find out why mongo is not simply queueing this and wait for a conflicting transaction to finish first.

Richard

09/18/2022, 2:10 PM

I wonder if there is a way to retry the query first in prisma. 🤔

Richard

09/18/2022, 2:54 PM

e.g. mongoose session.withTransaction has a retry behaviour:

Copy code

The session.withTransaction() helper handles:

    Creating a transaction
    Committing the transaction if it succeeds
    Aborting the transaction if your operation throws
    **Retrying in the event of a transient transaction error.**

Nurul

09/21/2022, 12:21 PM

The WriteConflict error is discussed here: https://github.com/prisma/prisma/issues/12814 This might be helpful to you. Having a retry mechanism in this case makes sense, can you create a feature request for this?

2 Views

Open in Slack

Previous Next