In 2.28. the table “TrackedEntityAttributeReservedValues” is storing unique ID values that have been reserved. When a request is coming from e.g. an Android device running Tracker Capture, the API will trigger the reservation of 100 values and return these to the device while also storing the reserved values in the above table.
Yesterday, I inserted a list of such reserved values into that table in order to “protect” a section of numbers that will be used for importing legacy data.
I then decided to verify that those case IDs WERE now actually reserved.
when using the normal browser Tracker Capture, it clearly worked - no case IDs coming up were in the reserved range
But when I fired up Android Tracker Capture and logged in afresh, the system did reserve 100 more values BUT a number of those were values already in the TrackedEntityAttributeReservedValues table.
Or in other words, it seems like a request for reserved values from Tracker Capture via the API will generate reserved values without checking if those values are reserved already - is that correct?
we haven’t really documented how this behaves when you do manual inserts of reseved values. Assuming the db insert did the same as a API reservation would have done, and that no caching is interfering what hibernate sees - the 100 new reserved values should not be among those preexisting in the TrackedEntityAttributeReservedValues.
I think this must have been caused by a hibernate caching delay. I deleted the additional records created by Tracker Capture now (after logging out from Tracker Capture), and then logged in with TC again - and this time the system actually generated 200 reserved values in two batches:
the first batch of 100 reserved values were created within 20 seconds
after 3 minutes, another batch of 100 reserved values were created, and this also took less than 20 sec
AND, more importantly, none of the 200 new values were among those pre-existing in the …ReservedValues table.
So my conclusion is that the only safe route after inserting reservedvalues directly is to re-start the server and thus make sure all caches are flushed BEFORE anybody can log in from a remote device.
Regards
Calle
···
On 19 April 2018 at 14:25, Markus Bekken markus@dhis2.org wrote:
Hey Calle,
we haven’t really documented how this behaves when you do manual inserts of reseved values. Assuming the db insert did the same as a API reservation would have done, and that no caching is interfering what hibernate sees - the 100 new reserved values should not be among those preexisting in the TrackedEntityAttributeReservedValues.
In 2.28. the table “TrackedEntityAttributeReservedValues” is storing unique ID values that have been reserved. When a request is coming from e.g. an Android device running Tracker Capture, the API will trigger the reservation of 100 values and return these to the device while also storing the reserved values in the above table.
Yesterday, I inserted a list of such reserved values into that table in order to “protect” a section of numbers that will be used for importing legacy data.
I then decided to verify that those case IDs WERE now actually reserved.
when using the normal browser Tracker Capture, it clearly worked - no case IDs coming up were in the reserved range
But when I fired up Android Tracker Capture and logged in afresh, the system did reserve 100 more values BUT a number of those were values already in the TrackedEntityAttributeReservedValues table.
Or in other words, it seems like a request for reserved values from Tracker Capture via the API will generate reserved values without checking if those values are reserved already - is that correct?
I think this must have been caused by a hibernate caching delay. I deleted the additional records created by Tracker Capture now (after logging out from Tracker Capture), and then logged in with TC again - and this time the system actually generated 200 reserved values in two batches:
the first batch of 100 reserved values were created within 20 seconds
after 3 minutes, another batch of 100 reserved values were created, and this also took less than 20 sec
AND, more importantly, none of the 200 new values were among those pre-existing in the …ReservedValues table.
So my conclusion is that the only safe route after inserting reservedvalues directly is to re-start the server and thus make sure all caches are flushed BEFORE anybody can log in from a remote device.
Regards
Calle
–
On 19 April 2018 at 14:25, Markus Bekken markus@dhis2.org wrote:
Hey Calle,
we haven’t really documented how this behaves when you do manual inserts of reseved values. Assuming the db insert did the same as a API reservation would have done, and that no caching is interfering what hibernate sees - the 100 new reserved values should not be among those preexisting in the TrackedEntityAttributeReservedValues.
In 2.28. the table “TrackedEntityAttributeReservedValues” is storing unique ID values that have been reserved. When a request is coming from e.g. an Android device running Tracker Capture, the API will trigger the reservation of 100 values and return these to the device while also storing the reserved values in the above table.
Yesterday, I inserted a list of such reserved values into that table in order to “protect” a section of numbers that will be used for importing legacy data.
I then decided to verify that those case IDs WERE now actually reserved.
when using the normal browser Tracker Capture, it clearly worked - no case IDs coming up were in the reserved range
But when I fired up Android Tracker Capture and logged in afresh, the system did reserve 100 more values BUT a number of those were values already in the TrackedEntityAttributeReservedValues table.
Or in other words, it seems like a request for reserved values from Tracker Capture via the API will generate reserved values without checking if those values are reserved already - is that correct?