My situation is that i have a page and the seller is going to take the order of a client, after the client orders, the seller hits the confirm button and awaits for the client to pass his identification card, wich i do with a ajax request and pop up a dialog with the list of products, a message and a cancel button.
After my ajax is sended in the server side, i'm doing a 'for' with a 'sleep' to check if the user has passed his card and then if he has, i put the items into his bill (persist into the database). The problem is, if that the user decides to cancel de proccess, i can't get the cancel ajax request to work because its busy with the first request on the server side and waiting its return.
Anyone have nay suggestions on that? I really wanted that the workflow of the site works like this:
Client orders -> Seller add the items and hits confirm -> Client passes confirmation or Seller can Cancel -> End of procces
Even if there was a simple way to do it the way you are going about it, this process would quickly overwhelm the server after more than a handful of connections.
I would store the customer's order to the database before requiring his identification, with a status field on the order set to "Awaiting Identification", or something to that effect. Then you can proceed with the identification flow without having to hold the PHP script waiting, and conserving a lot of resources.
If the client inadvertedly disconnects, you will still have saved her order and can allow her to complete identification at a later time.
Finally, when the client successfully completes identification, you can simply update the order 's status field to "authenticated" to indicate it's ready for processing.
EDIT: To address your particular problem, consider the following flow:
You save the order as "pending identification" and display the "Waiting..." dialog.
You perform a really simple request every few seconds asking whether the status of the order has changed, to know when the dialog needs closing.
At some point, the identification device sends a confirmation request upon which you retrieve the order and change its status. Then the periodic call you implemented in step 2 will kick in and hide the dialog.
The session is not a good location as a temporary storage medium, but a Redis, Memcached or similar service could help you simplify that process, given that the device and the site can in some way share information.