Node ID's

I.S._Support_(bupauser3_-_(deleted))

Hi I'm curious about the way in which LiveLink reserves node id's for each thread that is running and what level of control we have over it. I understand that each thread looks at the KID table, looks at the last number that was given out decides how many to reserve and increases the number in the KID table so that the next thread is then able to reserve another block of id's. What I would like to know is wether we can increase the size of the block that a thread reserves. Cheers

Find more posts tagged with

Comments

Kevin_Ward

Message from Kevin Ward <<A HREF="mailto:kward@opentext.com">kward@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

Livelink grabs 100 IDs from the KID table whenever necessary. These IDs are stored in memory until they run out and Livelink grab 100 more. Unfortunately, the 100 limit is hard coded in the underlying source code and can not be modified.

-----Original Message-----
From: eLink Discussion: Development Discussion [mailto:development@elinkkc.opentext.com]
Sent: July 11, 2003 8:57 AM
To: eLink Recipient
Subject: Node ID's

Node ID's Posted by BUPAUser3 (Support, I.S.) on 07/11/2003 08:49 AM

Hi

I'm curious about the way in which LiveLink reserves node id's for each thread that is running and what level of control we have over it.
I understand that each thread looks at the KID table, looks at the last number that was given out decides how many to reserve and increases the number in the KID table so that the next thread is then able to reserve another block of id's.
What I would like to know is wether we can increase the size of the block that a thread reserves.

Cheers

I.S._Support_(bupauser3_-_(deleted))

Hi How come I'm not seeing the value in the KID table increasing in chunks of 100?Cheers

Kevin_Ward

Message from Kevin Ward <<A HREF="mailto:kward@opentext.com">kward@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

Are you seeing KID being increased by 110? This is quite normal although I'm not sure why. Or did you mean you're not seeing it increase at all?

-----Original Message-----
From: eLink Discussion: Development Discussion [mailto:development@elinkkc.opentext.com]
Sent: July 11, 2003 9:53 AM
To: eLink Recipient
Subject: Hi

Hi Posted by BUPAUser3 (Support, I.S.) on 07/11/2003 09:42 AM
In reply to: RE Node ID's Posted by kward (Ward, Kevin) on 07/11/2003 09:11 AM

Hi

How come I'm not seeing the value in the KID table increasing in chunks of 100?

Cheers

I.S._Support_(bupauser3_-_(deleted))

We're currently running a process to create 15000 'Employee' folders (a custom module created by opentext), this creates a parent folder and 56 subfolders.The id in the KID table is jumping by the value 57 (ie the number of folders we're creating) and always matchs the highest dataid in the dtree table.Because these folders are being created in a transaction it looks as though the threads are locking each other out of the KID table as if we run multiple clients across multiple servers the is no increase in the overall upload rate. Therefore I was hoping that if we could increase the number of id's that are reserved then we'd be able to prevent/reduce the locking of the KID table. Does this make sense, or am I completely mistaken with regards to how LiveLink is working?Cheers

Francisco_Alcala-Soler_(iaea_001user3_-_(deleted))

Hi,I am not sure if this applies to your case, but now that you mention transactions, I had a similar problem with the 100-ID cache some weeks ago.When a thread picks up the next 100-ID block from KID within a transaction and the transaction is rolled back, the thread's cache is flushed and the thread enters a mode on which it starts to pick up IDs from KID one at a time.After this, I was encountering an increased number of deadlocks on the database when Livelink accessed KID. The scenario was a similar bulk object creation, like yours.It does look similar to your problem. Maybe this is why you see jumps of 57 IDs after you've created an employee's folders at a time. Take a look at your CONNECT logs and see if you've hit this problem.Open Text will patch this on a next release, I've been told.Regards, Curro

Magnus_Salgo_(IDNordicAdmin_(Delete)_2300172)

DOnt know what you do but there is a parameter on Start Transaction to ask for more ids/MagnusStartTransaction Integer StartTransaction( Dynamic connectOrLogin, [Integer numberOfIds] )Begins a new database transaction on the specified CAPICONNECT or CAPILOGIN. If a CAPILOGIN is specified, the connection used to allocate the login will be used in the transaction. The optional second parameter is useful for specifying the number of unique database ids this transaction will use. If the number of unique ids in a given user's cache is exhausted during the transaction, locking problems on the KID table may result.Transactions created via the CAPI interface are reference counted. This means that the initial call to StartTransaction will actually begin the transaction and subsequent calls to StartTransaction, made before an EndTransaction, will simply increment a count. This way, multiple levels of an application can implement transaction control without having to be aware of the controlling code.Parameters: connectOrLogin - The CAPICONNECT or CAPILOGIN to be used for the transaction. numberOfIds - The number of unique ids to reserve for this transaction. Returns: The Integer 0 if successful; Error otherwise. Here is an example:Integer status