Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 23 January 2009 09:29 -0600 Tom Barton 
<>
 wrote:

> > My main concern was with moving/copying a stem with 'many' children so
> > that the access/naming privilege checks don't impact performance unduly.
> > I'm not sure where the limit ought to be but it could be configurable
> > and profiling would help determine the limit. I'd try ~100 to start abs
> > see how that goes.
>
> I think there are two different objectives associated with limits like
> this. One is to manage the impact on performance because of its impact on
> user satisfaction with the tool. The other is to reduce the chance that
> the system itself becomes less functional and so unable to adequately
> serve all users.
>
> Which is it?

Potentially both. Anything that is very slow is likely to be CPU and 
database intensive which is unlikely to scale well. I presume we would 
attempt to do a move / copy in a transaction so the longer a transaction 
runs the greater the chance some one else will try an operation which may 
'conflict' with the transaction.

Chris: if a transaction was running for, say, 5 minutes, and in that time 
some one tried to update a group name - where the group is one of those 
being moved - how would hibernate handle that?

> And does move/copy expose the problem more so than other
> operations in grouper?
Shilen indicated that we would need to check that the subject doing the 
move/copy had appropriate privileges for every stem/group involved. We 
don't tend to do that elsewhere but it is the type of recursive call blair 
tried to implement that we abandoned.


----------------------
GW Brown, Information Systems and Computing