Hello everyone,

Can I change data during the synchronization of an Ultralite database?

We did some tests and there were situations in which the application crashed if we updated data during the download commit. In other scenarios, the sync fails if the data is updated/inserted after upload commit and before the download start.

We are wondering if we should avoid data manipulation during the whole sync.

If you have any documentation I'd like to read it as well =]

UltraliteJ for Android 16.0.2193

--- UPDATE ---

I build an example to test the "DisableConcurrency" parameter, but I didn't notice any difference. The data continues being inserted in the database.

Connection connection = DatabaseManager.connect(cfg);

SyncParms syncParms = ...
syncParms.setAdditionalParms("DisableConcurrency=1;");

connection.setSyncObserver(new SyncObserver() {

    @Override
    public boolean syncProgress(final int p, SyncResult data) {

        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    DatabaseHelper.newCommand("INSERT INTO Test VALUES('S_' || GETDATE() || '_' || NEWID(), " + p + ")").executeStatement();
                } catch(Exception ex) {
                    Log.d("SYNC", ex.getMessage(), ex);
                }
            }
        }).start();

        return false;
    }
});

connection.synchronize(syncParms);

asked 10 Mar '17, 13:23

Alex's gravatar image

Alex
1.1k274756
accept rate: 25%

edited 13 Mar '17, 14:56


Can I change data during the synchronization of an Ultralite database?

Yes, with caveats (of course).

According to the documentation on UltraLite Concurrency read/write access is permitted with the possibility that a download could fail under some conditions. Ultralite generally allows you to use an option to disable this level of concurrency. That is available through the UltraliteJ API.


None of that explains the crashing though. It may be related to something that has been fixed more recently than your build but it may be due to an undiagnosed problem. The timing of the crash with the download commit could be causing some sort of race condition and if it becomes a major concern for you, you should probably contact support so that can be looked into.

permanent link

answered 10 Mar '17, 13:49

Nick%20Elson%20SAP%20SQL%20Anywhere's gravatar image

Nick Elson S...
7.3k35107
accept rate: 32%

edited 10 Mar '17, 17:48

Contrary to the docs, you must be able to set the "additional" sync parameters on Android. If not, then that's a bug.

(10 Mar '17, 15:45) Tim McClements
Replies hidden

As Nick has pointed out, the caveat is around conflicting updates. If you modify something the download later needs to modify, the download will roll back. If you attempt to modify something the download has modified already, your request will fail with a locked/modified kind of error.

Certainly if you encounter a crash, please post the best repro info you can! (Not sure what you mean about not handling the sync, but again, things should work fine.)

(10 Mar '17, 15:52) Tim McClements
Replies hidden

Tim is correct about that being available with the UltraLiteJ API; using the setAdditionalParms( ) method of the SyncParms class. I've correct my original answer and have notified the doc team on the error.

(10 Mar '17, 17:45) Nick Elson S...

@Nick Elson S... What happens when the DisableConcurrency is set and I try to update/insert a register during upload? It would fail the statement? The sync would fail? The statement would wait until the sync if finished (holding the execution thread?)

(13 Mar '17, 07:48) Alex

@Tim McClements sorry, I was not clear about "handle the sync", but basically I have a guess about that sequence id error that I posted some time ago. I think it may be related to this issue. As we have a load balance, I was wondering if you change data during some critical phases of the sync would mess up the sync sequence information somehow. I'm gathering more information from the logs and as soon as I have it I will open a ticket, as you suggested.

(13 Mar '17, 07:52) Alex
1

Any insert, update or delete should block until the synchronization completes; when you have DisableConcurrency set to 1.

(13 Mar '17, 10:45) Nick Elson S...
Replies hidden

Thank you! Probably we will toggle this feature on.

(13 Mar '17, 12:06) Alex

@Nick Elson could you please check my update? I couldn't manage to get this working.

(13 Mar '17, 14:58) Alex

Sorry, I had to unmark this answer as accepted to make one more question about it. The documentation says database access is allowed in read-only state during the synchronization. Is that right? What happens if I try to commit a change during upload? Will the prepared-statement fail? Also, I tried to disable database concurrency, as @Nick Elson suggested, but I'm quite sure it didn't work.

(20 Apr '17, 09:20) Alex
Replies hidden

Can I confirm that you are seeing a crash and not an unhandled exception?

I would really like to see support cases opened so that we can investigate those crashes - or minimally details on how to reproduce those on the forum as it appears they occur relatively easily in your testing.

(20 Apr '17, 12:45) Chris Keating

What happens if I try to commit a change during upload?

The insert, update or delete DML statement should block long before you get to any sort or commit or rollback.

Will the prepared-statement fail?

The prepare will probably work ... is that not what you are seeing?

I tried to disable database concurrency but I'm quite sure it didn't work

It should take effect only during the active phases of the sync. What are you seeing? {maybe this is worth a new thread}

(20 Apr '17, 13:21) Nick Elson S...

Unfortunatelly it is not easy to repro the crashes. I tried a couple of times to open a support ticket, but with no success. I'll continue trying next week.

(20 Apr '17, 13:47) Alex

I haven't try yet (sync upload + prepared statement). I asked before testing to know what is the correct behavior. About the concurrency disabling, I thought the statements would be blocked during the whole sync. I didn't understood what you mean as "active phases".

(20 Apr '17, 13:50) Alex

You are correct -- concurrent requests should block for the duration of the entire sync request when you set DisableConcurrency=1. (But as discussed, you shouldn't really need this unless it's your chosen way to avoid row conflicts with the download. It may be useful in isolating your crashes, and in that case I suppose the first step is to determine why it doesn't seem to be working...)

(25 Apr '17, 14:28) Tim McClements
More comments hidden
showing 5 of 14 show all flat view
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×371
×84
×72
×38
×34

question asked: 10 Mar '17, 13:23

question was seen: 1,935 times

last updated: 25 Apr '17, 14:28