How long for "committing remote transaction"?

How long should one wait before determining that the synch procedure “committing remote transaction” has moved from an active process to a hopeless Hang state?

There is precious little information provided to a user about what this is or how long it should take. The activity bar gives no appreciable sense of scale or time.

Currently, I’ve been waiting more than 40 minutes. The last time DevonThink changed its synch technology I had a “committing remote transaction” churning for more than two days before I pulled the plug and started over. This was for a very large database (many gigs).

If the process does hang, then what? What’s the procedure to jump start the process as close to the end as possible, finish quickly, and dispense with the housekeeping so the real work can resume?

COMMENT: May I respectfully recommend some additional attention to User Experience; provide more useful feedback on the status of ongoing operations. This would be helpful. As it is, the activity window must be selected, then it routinely gets buried under the main window… It’s really hard to monitor progress of requisite processes.

For what it’s worth, DT’s über geek approach to software rather than a more mainstream UX, keeps me from recommending DT software to friends and colleagues. They would benefit from the software’s wonderful functions but would never tolerate\grasp the underlying geeks-only, no-help approach to functions as basic as synch.

If you’re interested in learning more about what is happening during the committing state, you can enter the following commands in Terminal.app:


  defaults write com.devon-technologies.thinkpro2 DTSyncDebug -bool YES
  defaults write com.devon-technologies.thinkpro2 DTSyncDebugHigh -bool YES

This will log more detail to your system log, which can be viewed in /Applications/Utilities/Console.app.

Unfortunately, there’s no easy way around this. Every sync, each record’s associated data has to be moved more-or-less individually from a temporary location to its final location.

Why?

Because Dropbox puts a 10,000-item limit on the number of items that can be transferred at one time.

The “committing” phase used to be lightning fast – so fast, in fact, that I didn’t even see the “committing” message most of the time. Unfortunately, it inevitably failed when the user had more than a couple thousand records in their database, which is why I had to put in a more complex recursive method, which itself went through considerable optimization.

The forthcoming Sync 2 changes this massively, since it has been designed from the ground up with Dropbox’s (and WebDAV’s, and the other stores’) strengths and weaknesses in mind. Unfortunately, there’s still a lot of work left to be done.