How does latch (isLatchClosed) work if multiple resources updated at same time

, , ,
1

I am reading guide about using cross-reference table to synchronize the data between multiple resources.

I am wondering if more than one source update at same time, how the latch (isLatchClosed) works.

The diagram on page 177 of Publish-Subscribe Developer’s Guide Version 6.5 just mentioned the updating from ONE resource. How about the updating comes from both Billing System and CRM system at the same time?

Can anybody give me an idea about it?

Regards,

Shuren

2

The latching applies to both systems. While the guide describes it in terms of updating from one resource, it is any resource, and both systems are potential sources for the information.
If both (or many) systems request the lock, exactly one will get it, the others will fail to acquire the lock and must suppress their updates. Later on in the Publish-Subscribe Developers Guide (p193), there is a description for N-way echo suppression, but the basic idea is that all of the integrations share one semaphore lock to indicate if it is alright to update. Since wM handles this part of the echo suppression problem, the real remaining challenge is to determine the appropriate response when the lock is set (e.g. rollback, try again later, etc), which of course is completely dependent on the situation you are dealing with.

Did this help?
-greg

3

I think this is a race condition problem.

let’s say we have following cross reference table in both source and target IS servers.

appId objected nativeId canonicalKey isLatchClosed
CRM system Account DAN0517 WM6308 false
Billing system Account 19970620 WM6308 false
Order Management Account acct0104 WM6308 false

Now both CRM system and Billing systems change data at same time. What is the value of isLatchClosed we can expected?

Also, I cannot find the information about “all of the integrations share one semaphore lock”. Could you tell me where you get it?

Thanks,

Shuren

4

Sorry to leave you hanging. I’ve been in crunch mode. Lets see. Don’t worry too much about the semaphore stuff, a semaphore is a flagging technique used to block a process. For example, the IS uses a LOCKFILE to try to prevent multiple ISs from running at the same time; this is an example of a semaphore.

I think that the section of the guide you are looking in (around p 177) is talking about two systems updating each other, so here is what to expect. Two (or more) systems change the same record at the same time. They each try to close the latch at the same time. The way the latch works, the database record is locked by whichever system is lucky enough to get their first. That is the system that will close the latch. The other system(s), will all fail to close the latch, and must rollback their transactions, and wait for the update from the lucky system.

Did that help?
-greg

5

Greg,

Thanks.

let’s say we have ServerCRM and ServerBilling. Both IS servers have cross reference table as following.

appId objected nativeId canonicalKey isLatchClosed
CRM system Account DAN0517 WM6308 false
Billing system Account 19970620 WM6308 false
Order Management Account acct0104 WM6308 false

Now both CRM system and Billing systems change data at same time.

On CRM side, at step 3 (page 177), the latch is closed.

CRM system Account DAN0517 WM6308 true

Now, at this moment, the udpate information frorm ServerBilling arrived at ServerCRM. Finding that the latch is currently closed, which indicates that the “change” has already been made, the udpate service does not make the update to the object. However, this time, the source of “change” is Billing, not CRM.

Further more, when the update infomation of CRM bounce from Broker, and will find the latch is open (opened by update infomation from Billing), it will update the CRM again.

How we can provent this happening?

Regards,

Shuren

6

The latching provides the signal that the update is occuring, but that is the extent of its power. You must code your flows to deal appropriately with the “latch closed” condition. Depending on your context, appropriately may mean “roll back”, “refresh your data”, “signal user that the record is locked”, “log collision”, or any number of other responses!

-greg