B4J Question Logic question, getting last transactions information

[AKJammer]

Hey All,
I've got a logic question that I'm pretty sure there are multiple answers to, but my way appears to be flawed, so I'm seeking better answers.

I have a registration table that will have one entry per person. They can then purchase many tickets as to need. When I go into ticket sales and they choose 1 or more tickets, and hit save, the first thing is to check the registration table to see if they are registered. If they are, I use the ID from Registration and tie it to the tickets table. If they aren't, I create a record for them, then re-query the MariaDB database to find that record and get the Registration ID.

The problem is that I have multiple computers going registering people and apparently I'm not finding the ID properly because I've got several -1's (the default ID) in the ticket table.

What is the best, or most elegant way, of getting the ID that's generated in the Registration table after I do an insert on a MariaDB database?

Thanks in advance.

Jim

 

[emexes]

the odds of two new registrations happening within the same second in real life is low, so I'm surprised you encountered the problem seemingly multiple times. Unless your testing had lots of simulated users continually banging out new registrations: then I would expect you to see the problem.

No its not.

I said low, not zero.

I wasn't surprised that it happened; I was surprised that it happened more often than expected, based on it sounding like selling tickets for a school event, which in my experience translates to like five hundred distinct purchasers (new registrations) spread over a couple of weeks.

That is why you write the record and then IMMEDIATELY get LAST_INSERT_ID. That should do it.

I think we're already agreed about LAST_INSERT_ID being the probable fix. And even possibly without the knife-edge timing ("IMMEDIATELY"), if this is correct:

query LAST_INSERT_ID which appears to be set on a per-connection basis

 

[MrKim]

I said low, not zero.

I wasn't surprised that it happened; I was surprised that it happened more often than expected, based on it sounding like selling tickets for a school event, which in my experience translates to like five hundred distinct purchasers (new registrations) spread over a couple of weeks.



I think we're already agreed about LAST_INSERT_ID being the probable fix. And even possibly without the knife-edge timing ("IMMEDIATELY"), if this is correct:

When I said "No it's not" I was referring low. I have found that users will ALWAYS find a way to break it if you leave an opening .