nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DTreeACL question - is there ever a reason for two entries with the same right ID and DataID?

HFCDev

Hi,

I'm posting in the developer forum rather than the OT General forum because I really want developer eyes on this, particularly anyone who has done Oscript for a decade or more.

For my government client, we've been tracking an issue where every so often, a duplicate entry appears in DTreeACL, where you have the same right ID, same ACL type, and same data ID entered twice, but not necessarily with the same Permissions. Our DBA has noted that (at least in SQL Server) all 6 field of DTreeACL make up a unique entry which allows such duplicates from a DB perspective. Programmatically, I'm asking if that makes sense, and if there is *ever* a reason why Content Server would want/need to create a second (or third) ACL for the same data ID and same user/group? The reason that this is an issue for us is that when such dups exist in the database, a folder tree can neither be copied nor moved because the perm check chokes on the duplication. We are running CS 10.0 U 2015-06. I suspect a race condition where one thread adds an empty ACL for a user, and another thread adds the empty ACL and updates it, not knowing about the other one.

And yes, we've opened a ticket, but we're not gettin anywhere with it as this is an issue that's near impossible to replicate. Hence I'm reaching out to the development community as our only recourse is to implement our own unique constraint on DTreeACL to prevent there from ever being two entries with the same DataID, RightID, and ACL type.

-Hugh

Find more posts tagged with

Comments

Kyle_Swidrovich

Hugh,

Even as a method of troubleshooting, the unique constraint could at least generate an error condition that would hopefully surface the root cause of this problem. Adding in any sort of DB constraint can lead to further performance problems, so it is unclear at this time what the overall outcome of adding such a constraint would be (other than avoiding the immediate problem).

Kyle

John Simon

Hugh,

Is the ownerid the same as well?

HFCDev

Yep, and the Parent ID and the ACL type. The only things that are different is the Permission and See fields.

-Hugh

eLink User

and you are ruling out playing with a sql tool.I think John was hinting on the recycle bin ownerid?

I do see for the same rightid one can get livelink to do this

You create a Folder.and lets say you allow a

func=ll&objAction=EditAcl&objId=50637376&id=50637376&rightId=247035&permType=2 //Targets same group as Group ACL

func=ll&objAction=EditAcl&objId=50637376&id=50637376&rightId=247035&permType=0 //targets same group as Below the line ACL

one is the owner group and one is assigned acl

.....appu appnair appunair

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

On Tue, May 3, 2016 at 7:34 AM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

DTreeACL question - is there ever a reason for two entries with the same right ID and DataID? 2 Posted byFerguson, HughOn 05/03/2016 08:30 AM

Yep, and the Parent ID and the ACL type. The only things that are different is the Permission and See fields.-Hugh
[To post a comment, use the normal reply function]Topic:DTreeACL question - is there ever a reason for two entries with the same right ID and DataID?Forum:Content Server Development ForumContent Server:Knowledge Center

HFCDev

hi Appu,

Here is what we see in the database for one of these (and we have more examples):

OwnerID   ParentID   DataID   RightID   Permissions   ACLType   See
-2000   46757778   46792309   47129417   128 0 0
-2000   46757778   46792309   47129417   258207 0 4

As you can see, the OwnerID, ParentID, DataID, and RightID are the same for these two entries, and they should create a unique constraint. Our current theory is this occurs during a permission apply to sub-items (which our users do *a lot*) and I suspect a race condition where one instance of the perms.apply request handler is doing a select to find out whether it needs to add a perm record or just update the existing one, and another instance has already gone ahead and added the entry but for what ever reason, it hasn't been committed yet or maybe it has, but the former thread somehow doesn't detect that.

I have suggested applying the unique constraint but the admin team here is nervous about that causing other more serious errors in a PRD environment which needs to be up 24/7. There is no doubt that if there was such a constraint, and the request handler thinks there is no entry, when it goes to add it, an error will occur but we don't know whether or not it will be handled (will it give an error message or simply go silent), and how users will react to the failure.

-Hugh

eLink User

Hi Hugh,

Not sure but since you are on a code snooping mood I will probably try this

Have a look at the private method LLNODE._NodeRightsUpade_ACLCommit

I would echo out (probably by a debug patch)

Assoc deleteACLAssoc, \

RecArray updateACLRecords, \

RecArray insertACLRecords, \

To me it looks like OT will do a Delete obviously in a transaction so I doubt if another thread does not have the updated info unless the db can be blamed

then it will update and then it will insert all logical....In the insert it will believe the list coming to it so unless the table prevents the additional entry or OT

is providing the list correctly(removing dups) you may have that situation.I know not.Maybe you can de -dupe it earlier somehow....That might save you the constraint putting head ache.

My theory is with that echo you may actually see the values coming into the call.

Also look at the corresponding record in dtree for the ACL Count.Does the count look like UGO+S+ number of ACl's or 1 less

maybe you will see something that may be working not like the original coder's

I looked in a 10 code base not sure if that's what you are running.

.....appu appnair appunair

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

On Tue, May 3, 2016 at 9:43 AM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Re DTreeACL question - is there ever a reason for two entries with the same right ID and DataID? 2 Posted byFerguson, HughOn 05/03/2016 10:38 AM

hi Appu,   Here is what we see in the database for one of these (and we have more examples):OwnerID   ParentID   DataID   RightID   Permissions   ACLType   See
-2000   46757778   46792309   47129417   128 0 0
-2000   46757778   46792309   47129417   258207 0 4 As you can see, the OwnerID, ParentID, DataID, and RightID are the same for these two entries, and they should create a unique constraint. Our current theory is this occurs during a permission apply to sub-items (which our users do *a lot*) and I suspect a race condition where one instance of the perms.apply request handler is doing a select to find out whether it needs to add a perm record or just update the existing one, and another instance has already gone ahead and added the entry but for what ever reason, it hasn't been committed yet or maybe it has, but the former thread somehow doesn't detect that.I have suggested applying the unique constraint but the admin team here is nervous about that causing other more serious errors in a PRD environment which needs to be up 24/7. There is no doubt that if there was such a constraint, and the request handler thinks there is no entry, when it goes to add it, an error will occur but we don't know whether or not it will be handled (will it give an error message or simply go silent), and how users will react to the failure.-Hugh
[To post a comment, use the normal reply function]Topic:DTreeACL question - is there ever a reason for two entries with the same right ID and DataID?Forum:Content Server Development ForumContent Server:Knowledge Center

Hans Stoop

Hi Hugh,

You should also include the ACLType in the uniqe constraint. The same group can be on the ACL and be defined as owner group.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Dienstag, 3. Mai 2016 16:44
To: eLink Recipient
Subject: Re DTreeACL question - is there ever a reason for two entries with the same right ID and DataID? 2

Re DTreeACL question - is there ever a reason for two entries with the same right ID and DataID? 2

Posted by Ferguson, Hugh On 05/03/2016 10:38 AM

hi Appu,

Here is what we see in the database for one of these (and we have more examples):

OwnerID   ParentID   DataID   RightID   Permissions   ACLType   See
-2000   46757778   46792309   47129417   128 0 0
-2000   46757778   46792309   47129417   258207 0 4

-Hugh

[To post a comment, use the normal reply function]
Topic:	DTreeACL question - is there ever a reason for two entries with the same right ID and DataID?
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Chris Meyer

Hi Hugh: It's a bug in Content Server. On my development instance I was able to simulate the conditions of overlapping transactions and this inserted duplicate entries in the DTreeACL table.

Christian Baillargeon

So how does this happen ? What lets the race condistion occur ?

HFCDev

My current theory is that the problem is in the CAPI drop-in. My reason for saying this is that I've seen instances where I make a change to a table in MS SQL Server Manager and commit it, then I run a section of Oscript in Builder that executes a query on that table, and I keep getting the old results. When I restart builder, it starts picking up the updated values. This never happens to me consistently so it's near impossible to reproduce, but to answer Christian's questions, here is a possible scenario:

Two threads, threadA and threadB are called by the permission update/push down request handler not far from each other. Thread A runs a query on the ACL of the folder it's acting on (that it got from the node crawler) it checks for the RightID of the permission being pushed down. It detects that it's not there, so it performs an insert into the ACL table. It commits the change. Thread B runs the same query, and for whatever reason, acts on the same node (this may be caused by a frustrated user clicking multiple times on the button, creating two independent node crawlers). It does the same query. 99/100 times, it sees that the ACL rec has been added for that user/group, so merely performs an update to make sure that it gets set to the updated value (CORRECT BEHAVIOUR). 1/100 times (or less), it *doesn't* get that ID in the query it does on the ACL for the object it's acting on, and assumes that it's not set, so adds the record. Because no unique constraint has been violated (if, say the original ACL was created as an empty permission, i.e. bitmask 128), a second row now exists.

What we've observed is that when this occurs, you see the duplicate entry for one or two users going down 3 or 4 levels. For OTDEV - this may be a caching issue with the CAPI drop-in, but a good way around this would be if users couldn't execute multiple permission jobs for the same root folder and same right ID - once they submit one, they cannot submit another (BTW, my BMUP product can do just this).

-Hugh Ferguson