Question about locking an order programmatically

[kqian]

Hi,

We have an integration scenario that needs locking of SoftPro order.
We have our own order data store that needs to be synchronized with corresponding orders in SoftPro whenever change is made in our side. We use a separate synchronization service to update orders in SoftPro. The problem is that if a user opens the order in SoftPro client too early before the update is processed, then it will fail when Sync service tries to update the order in SoftPro since the order has been locked by that user.
The way I am thinking to work around this problem is to lock the SoftPro order at the time of making changes on our side until the changes are sync'ed properly. That means one app will change our order data and lock SoftPro order, then the other sync service will pick up the changes, update SoftPro order and then clear the lock.

So is this a feasible approach? Is it possible to have one app lock the order and another app to do the update and clear the lock?
If it's possible, how can it be done? Any code sample would be more be helpful.

Or any other thoughts to handle this situation?

Thanks.

Kevin

[Graham Campbell]

Hi Kevin,

I do not believe that we have a way to share locks across applications, since the reason we have a lock is to prevent other applications from modifying the order while the current application is running. Either having your application acquire a lock or having a sync service acquire a lock may be appropriate.


Application lock pattern :

By having your app acquire a lock when you begin editing, you can give your users a clean experience by letting them know that they can't edit the order until a lock can be acquired ( aka, no save failures because our order is locked ). On saving your order you could immediately have that machine talk with the API, since you already used the API to get a lock, and update our system as well. This may be able to be done on a secondary thread so that it doesn't impact the flow of your application experience.


Synchronization lock pattern :

By not locking in your application, you could have a service that polls your system for orders that need to be updated and then attempts to acquire a lock in our system to perform the update. This would mean that our system may become out of sync with your system because it may be edited by a user prior to sync. However, even after a user edited the order, it would eventually sync in the changes from your system once a lock can be acquired.


You could even do a combination of these solutions or could have your application queue or pre-empt the sync process directly. I would recommend having the sync service poll for changes against some sort of storage though so that it is recoverable in case of a network outage.