Sometimes during mobilink synchronization we get the following errors in the log: W. 2013-09-27 16:00:06. <172> [10050] ODBC: [Sybase][ODBC Driver][SQL Anywhere]User 'DBA' has the row in 'ml_database' locked (ODBC State = 40001, Native error code = -210) W. 2013-09-27 16:00:06. <172> [10106] Unable to lock the remote ID '5ec6af40-1c44-11e3-8000-db904231408e', will try again After this message the synchronization hangs and the only workaround is to restart ML server. What can cause this and how to get rid of this error? SA: 12.0.1.3797 Mobilink: 12.0.1.3797 Ultralite client: 12.0.1.3797 |
The MobiLink server is reporting that there is a row already locked in the 'ml_database' MobiLink system table, indicating that the lock cannot be obtained in order to allow the current remote ID to synchronize. To the MobiLink server, this means that the older synchronization request is still 'active' and hasn't been timed out yet on the consolidated server. Are you running multiple MobiLink servers? If a synchronization request arrives on one server, drops the network connection and re-synchronizes on the other MobiLink server before the old request times out, this is an easy way to see this message. For more information, see SAP KBA #1899340. Are you running multiple MobiLink servers? Do you mean multiple servers for the same database? I know that there are other programs on the computer that use Mobilink for synchronization. But they use previous versions of Mobilink (11 and 10). Can they affect our synchronization?
(27 Nov '13, 02:03)
Mary Poltinina
Replies hidden
I mean specifically, do you have more than one MobiLink server attached to the same consolidated database? (e.g. as a MobiLink server farm?)
They will only affect activity on the server they are synchronizing to.
(27 Nov '13, 14:38)
Jeff Albion
It looks like the previous sync was blocked and the current sync from the same client could not get lock for the remote ID, it kept retrying again and again. If the previous sync was blocked forever, the current sync would retry forever (this retry algorithm can be improved). So you may need to find out why the previous sync was blocked. If you are not able to find why, please start the MobiLink server with the -tf switch. If the -tf switch is used, the MobiLink server will fail the sync, when a SQL statement in the sync is blocked for more than 10 minutes (this is the default time and it can be reset to any other values using the -tc switch). By the way, MobiLink server log files that contains this issue may help us to find out the problem. If you are planning to send us any MobiLink server log files, please remove all the user data before sending them to us.
(27 Nov '13, 16:48)
Yufei Guo
Thank you for reply. We will try what you offered. We have two publications in the client database: the first is to synch system information (short synch) and the second is to synch the main data. When the user initiates the synchronization we start the synch for the first publication. After it is finished we start the synch for the second publication. The problem always appears for the second publication. It starts but hangs with the error I wrote above. I know that there was a fix for the problem for Ultralite: User 'a_ml_user_name' has the row in 'ml_database' locked (ODBC State = 40001, Native error code = -210) But it was in ebf 3549 which is lower than we have. Is it possible that this error is still there?
(28 Nov '13, 03:39)
Mary Poltinina
Replies hidden
If you're referring to CR #687157, the error was not the specific message: "User ... has the row in 'ml_database' locked" - that message was only a precursor to the fact that we were not applying all rows in the upload once this has happened, in some limited cases - that was the error fixed. CR #687157 does not prevent the error message from occurring - the error message is still expected in the cases that we've described (an active synchronization is still occurring in the MobiLink server and another synchronization from the same remote ID is attempted).
Do you check the status of the first synchronization before attempting the second publication synchronization? If the first publication synchronization fails due to a network issue, you should wait at least the timeout length in order for the first synchronization to also be cancelled at the MobiLink server-side before trying another synchronization.
(28 Nov '13, 10:41)
Jeff Albion
It looks like this is an error message from the MobiLink server and the client change may not fix this problem. Could you please give us the MobiLink server log file that contains the hanging as well as the first and second syncs. It would be very helpful, if the MobiLink server log file is generated with -ves and without -vr.
(28 Nov '13, 10:44)
Yufei Guo
|