DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43136>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43136 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |blocker Target Milestone|2.0.1 |2.0 ------- Additional Comments From [EMAIL PROTECTED] 2007-08-16 07:52 ------- (In reply to comment #2) > > Stronger locking would mean to check out the sitetree repo node. You can do > this > by setting the usecase transaction policy to pessimistic (see usecase > framework > docs). This increases the danger of a checked-out sitetree which nobody can > edit > until a check-in is forced. > I agree, this doesn't sound like a good plan, people will hit back out of create and lock the sitetree causing huge amounts of issue. > Weaker locking is dangerous. Imagine the following scenario: > > * Alice opens the form to create /foo/bar > * Bob deletes /foo > * Alice hits "OK" > > With the current setting, Alice's transaction cannot be committed. If we don't > check for sitetree modifications, Alice's transaction would either override > Bob's changes to the sitetree (resulting in stale sitetree nodes) or run into > serious trouble because the parent doesn't exist anymore. > Yes, this could happen. But the alternative is worse. On a busy site (like when we're doing training with 20+ people at a time), a person may never be able to create a page. All of the atomic sitetree actions (nudge, delete, restore, etc) can be taking place much quicker than someone can fill out the form. They get an error message. Fill it out again, but someone else beat them to the punch. We don't have corruption, and it makes life easy for us, but makes it very bad for them. Chances are in many cases, actions will be taking part on different of the tree anyway. > If we don't lock the sitetree, we have to implement the usecases very > carefully: > > * reload the sitetree before committing > * check out the sitetree > * re-check the preconditions (parent exists, no node with same name) > * apply the changes > * commit the transaction > * check in the sitetree > This sounds good to me. I don't see that we have much of an option when it comes to usecases that modify the sitetree and wait for user input. We have to be able to support multiple users at the same time, and these usecases only do through luck or persistence of the user. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
