|
Timestamps are not an indicator of the order of changes on a multi-user system. In other words, changes are not available until the commit, regardless of when the user made the changes. SymmetricDS queries the changes periodically and orders by the data_id sequence. On a multi-user system, it could happen that IDs 1, 3, and 5 can be queried at 1:00, and then later it can query and find 2, 4, and 6 at 1:01. I think if you inspect closer, it is working as designed. |
|
|
I understand that, but I have situation when two batches was loaded. First from 2018-05-18 12:00 couple minutes later from 2018-05-17 22:00. Symmetric he was turned off for several hours and have a lot of batches to load (inventory table). |
|
|
Batches are loaded in order by batch_id. (It doesn't use time for ordering.) If there are multiple channels, then it load batches for each channel, ordering by sym_channel.processing_order. If there is a channel in error, then it changes the order of channels to make the ones in error go last. Can you check the channel_id and batch_id for those batches? |
|
|
I'm talking about one channel and one concrete table. This table have only one trigger and router. Channel is marked as transactional. On same queue I have two additional channels, one default, second default with big lobs.
In most cases everything is ok, but from time to time I see batch with inserts from strange date/time. |
|
|
Does it help to force a standard timezone for the sym_data.create_time? You can do that by setting parameter data.create_time.timezone=-5:00 in the engine properties file (restart required) or in sym_parameter. (It's an undocumented feature for Oracle.) After setting the parameter, you need to force a rebuild of triggers (symadmin -f sync-triggers). |
|
|
Auto closing all issues waiting for feedback after 4 months. We don't have enough information to take any action. |
|