DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26913>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26913 Lack of non-transactional history counter. ------- Additional Comments From [EMAIL PROTECTED] 2004-02-16 11:00 ------- It is not the problem of putting the same file without locking. The situation is that we are testing performance and stability of Slide for our application. In general test looks like this: 4 clients are putting simultanously about 2000 files (each file - 20 KB) in different locations (no PUT conflict). When putting them there are errors of type: HTTP/1.1 409 Conflict: Another object already exist at /history/2666 I have put some debug on slide sources, compiled and I found that SOMETIMES there is situation that two transactions (each for different PUT request) are getting the same I_NEXT_HISTORY_NAME property value of '/history' object (see "public static UriHandler createNextWorkingresourceUri" method in UriHandler class). I think it is due to the fact that I_NEXT_HISTORY_NAME property value is not increased until transaction is commited. So let's describe situation: We have 2 transactions: "A" and "B" each running for different PUT request on different file (with auto-version-control set to true so each PUT creates new folder in /history).Value of I_NEXT_HISTORY_NAME equals N. Scenario: 1."A" transaction started. 2."A" transaction : fetched I_NEXT_HISTORY_NAME and incremented to N+1 in synchronized method "createNextWorkingresourceUri" ("A" TRANSACTION IS STILL NOT COMMITED) 3."A" transaction left synchronized method "createNextWorkingresourceUri" ("A" TRANSACTION IS STILL NOT COMMITED) 4."B" transaction started. 5."B" transaction : fetched I_NEXT_HISTORY_NAME and incremented to N+1 (not to N+2 because "A" transaction was not commited so fetched value was the same as in case of "A" transaction) in synchronized method "createNextWorkingresourceUri" 6."B" transaction left synchronized method "createNextWorkingresourceUri". 7.One of those two transactions commited. 8.Second transaction causes exception because it cannot create the same history object. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
