Is there a replication delay in Salesforce.com via the APEX API?

views:

answers:

Is there a replication delay in Salesforce.com via the APEX API?

I have been using SOAP to deal with Salesforce.com and have been using the getUpdated() call, using the timestamp I retrieve from the getServertimestamp() call.

I have watched my process check, (it polls every minute) and a few seconds after I save the change in the Sandbox environment, I see it poll, get no <ids> in the getUpdated call, and then on the next poll, the modified id shows up.

Is there a backend replication delay in SFDC? I suspect there is, but have had no luck in identifying the magnitude of it. Anyone else experienced this?

Additionally, I realize I should mention, this is all in a Sandbox copy of the environment, which may confuse matters even further.

Update: I just tested, and I made a change, and my poll ran 48 seconds later, and did not see the updated object. But 1 minute 48 seconds later it did see it. So that is one data point. (I know my SOAP endpoint and Web interface are both running on the same server at SFDC, tapp0).

+1 A:

There's no delay in the recording of the change, but the getUpdate/getDeleted calls round down the specified time to the nearest minute, so a finish time of now, gets rounded down, and the just made change falls outside of the range.

Also, if you're doing near realtime replication via these calls, then make sure to pay attention to the inflight transaction timestamp returned, otherwise you can miss changes (as the change timestamp can't be the actual transaction commit time)

superfell 2010-07-26 02:35:31

Care to elaborate on what you think would be an issue with the change timestamp differing from the actual commit time? I am not sure I see the concern.

geoffc 2010-07-28 03:56:32

Sure, this should be covered in the docs, but here's an example.Say you have a update that started at 00:00:55 and the row's update timestamp gets set to 00:00:55, but the transaction doesn't commit until 00:01:02. If you call getUpdated at 00:01:01 for the period 00:00 to 00:01, you won't see this in flight change (because the tx hasn't committed), but if you blindly roll forward your polling window, the next poll will be for 00:01 to 00:02, and even though the update is now committed, the change timestamp is still 00:00:55, and so also won't appear in the 2 polls results.

superfell 2010-07-28 17:19:47

The closer to the current time you try and poll, the worse this problem is. The getUpdated results include the timestamp that the oldest inflight transaction started, and you shouldn't roll forward your polling timestamp past this timestamp, otherwise you risk missing changes.

superfell 2010-07-28 17:20:34

How long is the lag, typically between transaction start and commit?

geoffc 2010-07-29 00:55:54

it can vary wildly, a single row update, with no workflow/triggers etc it'll be very small, a batch update of hundreds of rows with workflow, triggers, delays waiting for locks and so on can have significant processing time before the commit (10's of seconds)

superfell 2010-07-29 03:22:53

@superfell: I think I get it. So what I do is, every minute an external counter kicks off an event. I call getServerTimestamp() and use that returned time as 'now'. Then I read back my last run time, and use that as beginning time. Then I ask for getUpdated between beginning and now. When that request is finished and processed, I store 'now' where I had 'beginning' before, ready for the next run through. This way I should not fall into the trap you are warning me of.

geoffc 2010-08-05 22:10:47

ansaurus

tags:

views:

answers:

Is there a replication delay in Salesforce.com via the APEX API?

related questions