This project is read-only.

Asynchronous synchronisation.

Jul 23, 2014 at 3:16 PM
Hi Guys,
We are attempting right now to use SLAM in our project. We have preatty big list which we would like to SLAM into MSSQL table. We have made a small modification of SLAM source code so right now all ItemAdded/Updated event recievers are called asynchronously. However there are still some ItemAdding/Updating ER's which are called synchronously. This has still impact on performance - after activating SLAM the save operation on the item takes about 3 seconds more than without SLAM... Is there any way to eliminate this issue? Would be awsome if we could synchronize our data completly asynchronously - so it would be 'silent' for the user... Any ideas?
Jul 23, 2014 at 3:24 PM
The synchronization process is intended to only be used when first setting up a SLAM on an existing list. After that point the SQL database is kept in sync in real time.

Maybe I'm not fully understanding how you guys are using sync?
Jul 23, 2014 at 3:29 PM
At various points SLAM has worked both ways. The current version does work synchronously, but it currently does so by design. SLAM supports a set of sub-actions that can be registered in code so that you can have some custom event occur prior to the item saving, after the item saves but before the item is slammed, and after the item is slammed. Of course making the ItemAdded/Updated events asynchronous breaks that functionality, and if you are not using then it doesn't matter for you. I am curious though whether the performance issue is based on the size of your tables? If you cleared the MessaegLog table and had an empty table would it still take 3 seconds to save?
Jul 23, 2014 at 9:11 PM
Thank you guys for quick reply! Well maybe I was not clear. I didn't mean the synchronization function from SLAM. By synchronization I mean the real time item synchronization. I will check brjenkins suggestion with MessageLog. I guess the issue is that while firing ItemAdded of the main item some other lists are modified during this time and other EventRecievers for them are fired and synchronized with slam. However 3 seconds it's lots of time and it should be much faster. Do you have any other ideas what should I check or what else could help me decreasing operation time?
Jul 23, 2014 at 9:27 PM
The first question is whether there is anything easy to do on the database side. If the MessageLog table is still small then I am wondering whether you are slamming any associations with items that are taking 3 seconds? Does a simple item take that long?
Jul 24, 2014 at 1:04 PM
After clearing MessageLog it decreased to 2 seconds. But still it takes lots of time...Any other ideas?
Jul 24, 2014 at 1:19 PM
Does the record you are slamming have associations (lookups)?