Grouper Developers Forum

[Chris Hyzer <>]

>
> 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.  :)

Regards,
Chris