Hello guys,

Please i need help on writing a PHP code to act as an web user database queue application. What i mean, is that, i am using php/mysql and i want to control users access to the database. Right now, different people can access my online application at the same time, so i am having challenge with the password they get when they register, i want to be able to give them unique id so i want a code to queue users request to the database.

Thanks

Generating a unique id for ur users as well as a unique password isn't a problem and u do not need to actually code a queue. The internal workings of the mysql database will handle that on its own. To generate uniquness I usually use a combination of three factors: Full timestamp of the entry, an auto_increment column which should be the primary key and the users chosen username and password. Combine this info in two separate columns and encrypt with any secure mode u desire. Make sure you separate the username & password data. When a user logs in through your secure form input the code will verify against the encrypted username & password in ONE-WAY fashion.

In addition:

If you are really concerned about a race condition then you might want to look at making your DB queries transactional so that when one person is signing up, the DB is "locked" and no one else can write to it until after the first person to "arrive" is done signing up. Thereafter, control is released and the next person in the queue is allowed to sign up.

I don't know what kind of site you are running, not to mention the level of user/DB activity, but if it isn't that high, I would say a transactional DB might b overkill.

As always, my 2 cents.

i'm sorry, i dont quite understand the problem here!

kheme,

I could be wrong but I think he is encountering a race condition in his code. So, using the analogy of 4 cars getting to a 4-way junction at the same time, each car is yielding to the other to make a move at the same time resulting in a deadlock.

If that is the case, given the fact that I only know enough PHP to make me dangerous (as opposed to deadly), I could also be wrong in saying that PHP doesn't support threading hence my post above about using a transactional DB.

Again, I could be wrong but I think that is what he is talking about.

@ chukkynze

Thanks for your advice. I really appreciate.

@ my2cents

Thanks my brother, you just understood the problem one hand, making the database function like a transactional database is the challenge. I use oracle and in oracle its not a problem as you have to specify during development if you want warehousing, transactional or production database but in MYSQL, there is ISAM, INNODB and some stuff, i am suspecting that one of the two must be transactional, but i am still doing my research and trying out some new things.

There is no problem with my site and the traffic, the only problem is when two users have to request for password from the server at the same time, in that case MYSQL assigns the same password to the two, that is what has been happening.

Well, again I could be wrong but I think ISAM is the default for mySQL tables. To use InnoDB, which supports Transactions, you have to specify InnoDB as the DB type when you create the table.

I am sure there are plenty of tutorials out there you can get more info on about mySQL transactions.

Good luck!

Why dont you generate a random password in your application and store it in the database instead of relying on the db to do this for you.

candylips,

Again I could be wrong (sorry for saying this so many times but I don't like talking authoritatively on things I haven't verified for myself to be true) but given a race condition which, though maybe not ever happening, is still a possibility, there is a chance that even if a timestamp is tacked on to the password, that 2 registrations come in at the very same millisecond in which case, the same password would still be inserted into the database.

I think the perfect solution is to make the DB transactional. That way, the DB funnel, so to speak, is locked down, updated, then released for the next registration in the queue.

Just my 2 cents.