Closed Alfiva closed 7 years ago
Original author: @Alfiva (2015-07-30 12:15:55)
Won't fix: this happens in very rare exceptions, and when clients misbehave. Also, if this error appears, nothing happens, it will just keep working.
issue cloed on 2015-07-30 12:15:55
Originally Opened: @Alfiva (2015-06-10 16:38:53) Originally Closed: 2015-07-30 12:15:55
It SEEMS that when two REGISTER messages arrive at the R API manager in close proximity, from the same tenant, there is a risk for a concurrent modification of DB. The following is the theory, since I could not check myself, but it looks like this could be it:
A MySQLIntegrityConstraintViolationException occurs, with the message: Duplicate entry 'whateverTenantID' for key 'PRIMARY' launched in R API at PersistenceMySQL.storeRegister:147, from RemoteServlet.doPost.
This means that R API is trying to save the register ID (GCM key or URL) associated to a node id (whateverTenantID) in the DB, but the entry already exists.
Because I cannot use IF NOT EXISTS in both MySQL and Derby, I have to check the existence of the node id in advance, with another DB query. If it exists, then UPDATE the DB, if it doesnt, then INSERT the data. The error may manifest because, if 2 REGISTER R-API calls happen in proximity, the following sequence happens:
1-REGISTER call 1 checks there is no whateverTenantID entry 2-REGISTER call 2 checks there is no whateverTenantID entry 3-REGISTER call 1 inserts the entry SUCCESSFULLY 4-REGISTER call 2 tries to insert the entry but FAILS
This bug, if it really happens like this, is quite marginal, because: -Was only found once after using R API for months -Is highly unlikely (or wrongly programmed) that a remote node sends 2 REGISTER calls to R-API so close to each other. -If it happens, R-API keeps working, only that the failing REGISTER will be skipped. Which is not a problem, because the first REGISTER did succeed. The only real problem would be if the second REGISTER was an update of the GCMkey/URL, but it is even more unlikely that 2 REGISTER calls with different key/url were sent in proximity.
Possible solutions: Synchronize DB access in this case
--
From: this issue has been automatically imported from our old issue tracker