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: Chris Hyzer <>
  • To: "GW Brown, Information Systems and Computing" <>, 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 10:52:42 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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

Btw, We have had memory problems in the loader when huge transactions do lots
of things... so I think for the loader we turned transactions off by default.
However, a stem move is different because if a loader half completes, you
are halfway there, but if a stem move half completes, you could be in
trouble. Actually the way the loader works is each smaller item of work is a
transaction, but there isn't one around the whole thing... so maybe it is
similar... move one group at a time, each group move is a transaction
(including all the memberships), but then not the whole thing. If we could
find a way to do something like that, it would really make it a lot better.

Regarding your question, if a transaction lasts for 5 minutes, hibernate just
passes the work to the DB, so whatever the DB does for transactions is what
hibernate does. So if you are using an old version of mysql, it will lock
the whole table I believe. If you use a real database (including recent
versions of mysql I believe, oracle, postgres, etc), it will lock the row.
So if someone tries to update that row, then it will wait for the first
transaction. In the case of a stem move, it might give bad results... i.e.
it might rename the group back to what it used to be. If we turn on
hibernate versioning, then it will cause a failure for whoever is updating
the locked row, since hibernate will increment a version number and the row
is stale. I have the hibernate version column in there, so we can enable
this, the only thing holding us back is we update the group last_edited for
every membership change, if we can either not do this, or not do this with
hibernate (just send an update statement), then I think we are all good. If
you are changing memberships during a stem move, then maybe it might work if
the stem-move isn't deleting or changing that membership row.... lets see
how it goes :) OK, this was probably a lot more confusing than clarifying,
send me more questions about the hazy areas. :)


Archive powered by MHonArc 2.6.16.

Top of Page