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 ------- Additional Comments From [EMAIL PROTECTED] 2007-08-15 16:05 ------- (In reply to comment #0) > It would appear that we need either stronger or weaker locking. Either we > strongly lock the sitetree on any operation, including going to create. Or we > don't lock the sitetree until create is hit. People can't fill out the create > form as quickly as a script can. At least it is no longer creating entries in > the sitetree without the content being present. 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. 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. 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 -- 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]
