The unique number could serve as a session identifier. If the basic constraint is that you want to carry out just one database insert for each unique id, you need to make sure that the session id generation mechanism can't be triggered to hand out fresh ids when unwanted and also that no two different users will get the same id.

As for the other part - transactions - you need to ensure that no matter how many times a request (with the same session id) is submitted, the insert is carried out just once. That can be done in a number of different ways, a simple one is this (pseudocode) - having a primary key on session_id in table:

sub my_request {
    my($session_id, $data) = @_;
    eval {
        <insert $session_id, $data into table>
    };
    if($@) {
        if($@ ne primary_key_violation) {
            <Handle error>
        } # No else, since the primary_key_violation
          # just means that the data has been inserted
          # by another request
     }
     <Print everything is okay>
}
[download]

The main catch in the code above is not to treat it as an error condition if you discover that the data has already been inserted. Depending on the way you initialize DBI and the driver, your may get an exception when violating a constraint. If you can't get it to throw an exception, you can check your statement handle for any errors.

Remember to encapsulate everything in a database transaction if you carry out multiple database operations. By doing this, you can do a rollback if you detect that another request has inserted the data already.

(Sorry - the above post was just me again. I forgot to log in.)

Consider looking a little closer at this term:

Idempotent (Wikipedia).