I hate the Status 499 (http_response)

I have a big problem with this * status.

1. I send some value to my server PHP/MySQL
2. The insert SQL is done. Successfully
4. Server return: echo 'OK_INSERT';
3. SL receive, somentimes but sometimes, status 499.

Well... The insert in database is ok, but something wrong with htttp_response:
The problem:
If mysql_query("..." is FALSE, i return FALSE.
If other status (503,404..) occurs, then i can SEE the failure in the body param.
If mysql_query("..." is TRUE i return TRUE.
Allright, great!
But....
If the status is 499 i can't know if the mysql_query("..." function return FALSE or TRUE because the body param is empty... And sometimes is TRUE and sometimes is FALSE.

Problay is the timeout in all cases... But I can't be sure because http_responde is poor.

Why LL don't create a socket for LSL???

Please people! i need help!

NOTE: I can't check the result with other request, and if i do this... Can receive the same problem 499,499,499,499,499,499!!

I hate the 499! lol

Thank you very much!


(sorry the english)

If you don't get a valid response after the insert, I'd issue a second request to the database, querying for the record you just entered.

I talk abou this in the NOTE... The problem is that i can't get the new ID of the database, just should try compare using the same values, or creating some new filed in the table with the unixtime or some flag to compare.

I think that i will do this, but is not a good implementation. Probaly will get the same error, and then need test more one time, and more, and more, until the status be !=499.

ty

When you want to know what the last inserted ID in the table was, use a MySQL-command like this:

SELECT LAST_INSERT_ID() FROM myTable

This will return the last ID inserted into the table. ID needs to be a column that has an auto-increment-value.

If this request results in a 499 again, you have to issue another http-request, that's true...

OK...But the last ID is could be generated by other object. The ID don't could be used in my case... As i say, to verify in other request i will need create some field for this purpose.

I think in one unixtime filed, then i send the same informations and I compare with expected insert in a limit of seconds. BUt the same informations could exist in diferents registers, just the ID not. But, as i say, ID is probaly of others transactions, and a autoincrement field. Id a get SELECT LAST_INSERT_ID() i will get a probaly wrong information.

If you have multiple objects saving data to this table, I'd store the key of this object in the table then. So you could issue the 2nd command something like this:

SELECT id FROM myTable WHERE objID = '<lsl-key-here>' ORDER BY id DESC LIMIT 0,1

This will return the last ID inserted by this object.
Not very elegant, but it'd do the job...

If this happens often I would work on making your script and overall system more tolerant of duplicate entries. That's more friendly in terms of concurrency. Unless, that is, you are absolutely certain your table(s) is used only by this one script in only one prim throughout SL and that's the way it will continue to be until your database is redesigned.

For example, if some (combination of) the fields you are setting on insert should be unique to each entry, make that a (primary) key of your table. Then either return a recognizable error to the script when a duplicate is entered and have the script issue a second request querying the details of the row (if necessary), or have your server-side application layer do similar (with the HTTP request basically turning into "insert or find the entry with key <id> and return these fields".

If the only unique keys you have are synthetic, you're going to have a slightly more difficult time figuring out what to do. Perhaps add a timestamp to your rows and on 499 try to find the latest one with the same details as the entry you are trying to insert. If none exists or one exists but it is over a certain age (i.e. was created before your initial insert attempt), the insert never completed and you should try it again. This is slightly less risky than simply grabbing the last inserted row in the table as suggested by others above, but still may be very prone to race conditions, depending on the nature of the data and scripts you are dealing with.

Note also that LAST_INSERT_ID() is not a unique value; it is specific to the database connection. So unless you have a persistent connection and the same process will be making both queries (unlikely, and depends a great deal on your HTTP server), it is probably not going to help. LAST_INSERT_ID() is often only useful in web applications in the context of servicing a SINGLE HTTP REQUEST.

Absolutely right, Hewee - I kinda misread the MySQL-Manual regarding the LAST_ENTRY_ID (as a result of lack of coffee, I guess

«For LAST_INSERT_ID(), the most recently generated ID is maintained in the server on a per-connection basis. It is not changed by another client. It is not even changed if you update another AUTO_INCREMENT column with a non-magic value (that is, a value that is not NULL and not 0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously from multiple clients is perfectly valid. Each client will receive the last inserted ID for the last statement that client executed.»

This means, that one could use LAST_INSERT_ID() right after the insertion is done and then return this to the http-request (which - in case of a 499 - will not work).

So - my apologies for giving misleading informations about that...

My last suggestion was not really complete either. One would have to store the last inserted ID made by the object in the (sl)script. So upon making another insert, getting a 499, one could make a request to the DB, asking for the last id that was inserted by this object. If it's the same as the one stored in the script, the insert failed (the server script would have to return the last inserted id to the sl-script).
But - as you stated - if the insertion is only half complete, this would not produce reliable results. So in case of a 499 it would be necessary to compare the stored values in the db with the ones that should be stored in the sl-script.

TYVM, both.

I implemet some like that...

In the table exist a time filed,.. Well before I get with PHP, now the script send the unixtime and later I verify if exist some register with same unixtime and avatar. For now is the only way that I can picture.

I will still waiting for the "Socket4SL"...Maybe one day. And now i neither verify the satus, only the body, because the ESPECIAL 499.

Thank you for your help guys!! And sorry my very bad english lol