You are viewing limited content. For full access, please sign in.

Question

Question

False Simple Synchronization Sequence functionality?

asked on November 7, 2013

 I seem to not understand what happens with Simple Synchronization Sequences.

 

As I understand it you can use this workflow activity to restrict access to certain activities to ensure that one workflow or part of a workflow is not acting on entries and other activities when they are being used by another workflow or other part of the workflow. 

 

In testing, I have found that it will merely wait the max time set and if it was still not able to access the activities within, it will just run them anyways. This seems counter-intuitive to ever other lock-out mechanism in other programs/programming languages. 

 

Has anyone come up with a solution to working with this functionality to create an effective lock mechanism. This does not seem to follow the 4 principles of a good lock mechanism and is almost like adding in a layer of risk to a workflow as the results can be inconsistent and the performance as well.

 

1 0

Answer

APPROVED ANSWER SELECTED ANSWER
replied on November 7, 2013

The simple synchronization sequence is not intended as a locking mechanism. And it is definitely not meant to prevent another workflow from accessing an entry for the entire duration of the current one. It is meant as a temporary very short lived lock to handle the situation where multiple workflows are trying to access the same entry at the same time.

 

In the case where multiple actions are trying to lock the document at the same time, one of the actions succeeds in the Laserfiche server, the other get "entry locked" errors. The Workflow activities that get this error then wait for 5 minutes (or whatever wait period you specify in the Task Error Handlers in WF Admin Console) and then retry the action. If they get an error again, they wait and retry again until the action succeeds or the maximum number of retries is hit.

 

Some customers have complained that waiting for a few minutes it too long, and they'd like it to retry almost immediately. So the simple synchronization sequence gives you an immediate retry mechanism. If the action cannot be completed after the specified time, it goes through the regular retrying mechanism (aka, the task error handlers).

 

Unlike the task error handlers which persist the instance while waiting, the simple synchronization sequences are in-memory locks that will slow down your Workflow server's performance if used excessively.

 

Maybe you can describe your use case in more detail so we can give you a better solution/recommendation?

 

Miruna Babatie

 

Software Test Engineer

Laserfiche

1 0

Replies

replied on November 7, 2013

Hello Kenneth,

 

The Simple Synchronization Sequence activity is described in detail in the Workflow help files. It is meant to help sort out delays stemming from multiple workflows acting on the same resource at the same time. Note that the help file includes scenarios in which someone might want to use this activity.

 

The Simple Synchronization Sequence will wait for the configured amount of time for other sequences to finish what they're doing. If the other sequences don't release the resource in time, yes, the activities inside of the sequence will risk running into an entry locked conflict or a similar delay. There is a subpage in the help files dedicated to synchronization options. This is the intended behavior.

0 0
replied on November 8, 2013

I think my idea of the Simple Synchronization Sequence activity is a lot more clear now. I think that I may need to create a SQL table to reference within another workflow and it would basically have a synchronization ID and the entry ID of the file a wait condition is waiting on in the original workflow. The original workflow then would be able to update a files metadata and then wait for that metadata to be changed back. A subworkflow would then be looking for this field and when changed by the parent, add a row in the SQL table and then terminate.

 

That may be confusing but its basically, 2 extra workflows:

1. updates the sql table based on an entry

2. updates the entry based on the SQL table. 

 

Another idea I have had to get the functionality I want would be to have a workflow that I invoke that sends certain parameters that will be set to wait for completion before running the next activities. 

  -The sub-workflow would be an activity handler so that when I want to use the same ODBC driver connection only 1 workflow is acting on it at one time. 

0 0
replied on November 8, 2013

Why not just have only one workflow start through starting rules and invoke the next one when it's done and so on?

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.