Hi. I am new to Ktor and I have a problem. My pro...

# server

[Carlos Valencia]

Hi. I am new to Ktor and I have a problem.

My problem is that items in database have a numeric id that needs to be increase by one each request.

Right now if I receive 2 or more requests at the same time they query the same last item from database having the same item.

I need to wait until the first request is completed before accepting a new one, so I can keep the correct order in the database. Something like a request queue or Channel or similar.

So, my question is. How can I make the pipeline sequencial? and wait until it is completed before starting a new one?

Untitled.kt

[Johann Pardanaud]

I don’t think this is something Ktor should solve for you, it’s too specific.

An easy option could be to use a Semaphore with only one permit, you acquire it before fetching the last item of your database, and you release it after inserting your result.

The reason I’m talking about a Semaphore instead of a Mutex is because the former maintains the a FIFO order.

However, if you have a high traffic this will not scale because all your requests will be run sequentially.

[Rohde Fischer]

without knowing the full scope of your project, I will hazard a guess which could be wrong for your specific case - but with 99.9% certainty isn't

the short answer probably: no you don't!

slightly more detailed, ensuring atomicity in your data should not done in the application but rather the database - if at all. You don't want to prevent yourself from horizontal scaling in the long run, even if you're unlikely to need it in the immediate future. So if you actually want incremental IDs (you probably don't, see next part) look into SEQUENCE, auto_increment or whatever that beast is named in your DB

if you need any kind of FIFO order of your things, I recommend timestamps and accepting that you will not (and cannot - ever!) get true FIFO, so if you get two identical timestamps, just accept the random order, it's not a problem (reason you cannot get true FIFO anyway is IO latencies and the unpredictable nature of IT systems as a whole, the idea of everything being perfectly up to date is an illusion anyway)

which leads me to the next point. Are you really sure that you want incremental numbers for your IDs? Probably you will be better off using `UUID`s, which removed the need for DB logic for atomicity to begin with and is much more scalable and robust in the long run (at least for most cases)

[Johann Pardanaud]

Actually, a better option to handle the traffic could be to:

• create a MySQL transaction (or postgresql/whatever)
• insert an empty row
• retrieve the ID of the inserted row (other transactions will not see the new row until committed but they will use increased IDs anyway)
• make your request to the other server
• then update the inserted row with the response
• commit the SQL transaction
That way you can have as much concurrent requests as your database can handle 🙂

[Johann Pardanaud]

And I agree with @Rohde Fischer, if you can avoid using incremental IDs, that’s even better.

But if you need them, for whatever reason, my second message can help you using them and maintain a correct throughput.

[Carlos Valencia]

Thanks for you answers.
I cam explain the full scope of the project. Or Tlat least the request.

I can pay for a consultation if you are OK with that. I am respectful of your time.