Quasi-concurrent Java methods invocation in D2 Lifecycle?

Options

Quasi-concurrent Java methods invocation in D2 Lifecycle?

Hi everyone,
I'm dealing with an annoying problem with Documentum D2 22.2.

I have a Lifecycle which, for a certain status, launches two custom Java methods, in sequence, let's say MethodA and MethodB both applied to the same document object (they are configured in the Action of the Lifecycle state).
MethodA performs a series of operations, updates a field and saves the document object.
MethodB uses the newly modified field to perform other tasks that do not require another save of the document object.
I was convinced that by configuring the two methods in the Lifecycle, they were executed with a kind of FIFO queue, instead I realized that MethodB is invoked before MethodA terminates.
The result is that MethodB does not see the field modified by MethodA and therefore does not work correctly.

I tried to interpose some non-impactful change between the invocations of the two methods (e.g. the reapplying of security or the fake modification of a field).
In fact, by doing so, the execution of the two methods appears separate but another error emerges which seems to indicate a concurrence of modifications on the same document object (DM_OBJ_MGR_E_VERSION_MISMATCH); it is as if MethodA and the interposed modification try to modify the document object at the same time, thus making MethodA fail.

Does anyone have an advice on how to make the execution of the two methods invoked by the Lifecycle strictly sequential?

Thanks in advance.

Tagged:

Comments

  • If those are in-house developed methods, maybe you could in your lifecycle only launch Method A and in Method A, you launch Method B at the end….

    My 2 cents

  • This behaviour happen if Method A is asynchronous, otherwise it would be as you expect, and method A would finish before method B starts.

  • @Loic HERVE has it correct. If you want the method to execute sychronous, uncheck the Run Asynchronously (in DA under Methods, property page of the method in question). Unchecking Async will require the method to complete and return before it proceeds.

    For better control and more efficient operation, your new approach of combining the methods into one (suggested by @Franky Dee ) is a good approach as well.

  • For my point of you, making the methods synchronous would work fine if they don;t take too long to do their job but if they do some big processing that might take a while, I'm not sure the users would have the patience to wait for both methods to have finished and would swamp their support team with performances complains…..

    I'd say, if you methods do a quick processing, then make them synchronous and here you go. If they take a long time, I stand by my suggestion…..