Concurrency/Latency problems when using UpdateNode method

Cheryl_Bellamy

We’ve implemented a webservice that works as a Façade (https://en.wikipedia.org/wiki/Facade_pattern) to OpenText. It exposes an UpdateDocument action, that is able to call many CWS methods to update different aspects of a document, in a single integration transaction.

 

Among these methods, we are using CWS’ UpdateNode to rename a document. In some situations, the same document (same node) can be renamed twice, within a  short time frame. The transaction sequence could appear something like this:
1) initial node name: “Document 1.docx”;

2) first update comes, trying to rename it to “Document 1 – version 2.docx”;

3) 1 second later, second update comes, trying to rename it to “Document 1 – version 3.docx”;

 

All updates are apparently successful (as no exception is thrown), but the document remains as “Document 1.docx”, because neither update achieves the desired outcome.

 

If the gap between the renames is larger e.g. 10 seconds instead of 1, the updates are successful as the renaming occurs as expected.

Is there any way of detecting a "failure" when executing the UpdateNode transaction

appuGmail

I am not sure if your code uses transactions per se or if you are referring to discrete calls to an otherwise   discrete element of work(API)

From delving in OT internal code for some time I know that Oscript uses Transactions to basically safeguard your calls against accidental

code misbehavior and it works in a nested way. So if the first call has given you a success more than likely you will see a commit in Connect logs.

To do a deeper analysis OT and everyone in this forum will ask you to provide debug output which is usually achieved like this

1. On the Livelink server which acts as the host responding to your code one would put wantLapiLogs=true,wantLogs=true, and Debug=2.In 16 servers these logs exist in different sections but the idea is the same, we want DB logs)(connect) we want thread logs and we want lapi calls to show up in the logs. One thing is LAPI here does not mean the old lapi product but the way OT programmers create a bifurcation in the dispatch mechanism something to differentiate from browser vs fat client...
2. If possible consider changing the log path to a UNC share so there are enough logs to accommodate the anomaly you want to present OT sometimes it's a wild goose chase because the logs become so huge that you cannot do any qualitative analysis...
3. Re-architect using best practices a few for API is put things to a sticky server and don't let web requests crowd the API server and so on...
4. Usually, a combination of Thread and Connect will give the clue. A presentation by Doug Gillespie of OT if looked at will tell you how to look at the thread and connect together so it provides meaningful info. In the ever-changing world of rebranding, many things that people could find in the OT Livelink KB takes time to search. I remember names on good articles I remember so that's the reason why you could do some search like "Doug Gillespie, Logs"   and you may find a webinar or ppt.

I looked at NodeRename in services code, it will invoke a $LLIAPI.LLNodeSubsystem.GetItem( 144 ).RenameNode showed for clarity as a document subtype and basically, it will be executed in a transaction

at Livelink server side.

Ciao,

..... appnair appunair( Livelink Rocks  )

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937 

On Sun, Oct 7, 2018 at 6:22 PM eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

Concurrency/Latency problems when using UpdateNode method

Posted bycheryl.bellamy@datacom.com.au (Bellamy, Cheryl)On 10/07/2018 07:21 PM

We’ve implemented a webservice that works as a Façade (https://en.wikipedia.org/wiki/Facade_pattern) to OpenText. It exposes an UpdateDocument action, that is able to call many CWS methods to update different aspects of a document, in a single integration transaction. Among these methods, we are using CWS’ UpdateNode to rename a document. In some situations, the same document (same node) can be renamed twice, within a  short time frame. The transaction sequence could appear something like this: 1) initial node name: “Document 1.docx”;2) first update comes, trying to rename it to “Document 1 – version 2.docx”;3) 1 second later, second update comes, trying to rename it to “Document 1 – version 3.docx”; All updates are apparently successful (as no exception is thrown), but the document remains as “Document 1.docx”, because neither update achieves the desired outcome. If the gap between the renames is larger e.g. 10 seconds instead of 1, the updates are successful as the renaming occurs as expected.Is there any way of detecting a "failure" when executing the UpdateNode transaction

---

[To post a comment, use the normal reply function]
Forum:	Content Web Services Forum
Content Server:	My Support