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-31 14:06 ------- (In reply to comment #18) > Maybe there is a timespan between the loading and the locking of the sitetree > in > a session. If the sitetree is changed between these events, the changes will > be > overwritten: > > 1. Session A loads sitetree (revision 1) > 2. Session A adds node 1.1 > 3. Session B loads sitetree (revision 1) > 4. Session A saves sitetree (check-in of revision 2) > 5. Session B locks sitetree > 6. Session B adds node 1.2 > 7. Session B saves sitetree (check-in of revision 3) > > At this point, node 1.1 will be removed from the sitetree. > > We have to avoid the timespan between loading and locking. Actually I can't > imagine how this occurs since the locking of the sitetree repo node is the > first > action when the transaction is started, it should happen before the tree data > are loaded. I'll add a check and run some tests. r571429 said you added code to detect issues related to this comment. Do a clean build, import into default publication, submit a page, then publish it. It will always trip your detection code. I just rolled back to that revision and am still having trouble, so it's not anything I've done today to make this trip. Given the time line, it might have something to do with publishing pages. -- 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]
