Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper design call, Wednesday, 21 January 2009, 1200EST (1700Z)

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper design call, Wednesday, 21 January 2009, 1200EST (1700Z)


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>
  • Cc: Shilen Patel <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Grouper design call, Wednesday, 21 January 2009, 1200EST (1700Z)
  • Date: Fri, 23 Jan 2009 15:42:41 +0000

--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




Archive powered by MHonArc 2.6.16.

Top of Page