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. [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Enhancement |Critical ------- Additional Comments From [EMAIL PROTECTED] 2004-02-16 15:56 ------- >I guess I understand now. Even though in this special case the problem seems to >be caused by the cache having unsufficient isolation, if it wasn't the cache >then it would be the file or relational database. -It has proper isolation and that because of it state of objects from uncommited transaction is not visible. >I understand it would be nice to have something like a sequence, but as this is >no permantent error and no inconsistent data is written I will reduce severity >to enhancement. > >If you think this is not adequate, please explain why you think it is critical. >.. -It is VERY CRITICAL because ONLY 2 internet explorers uploading files as described in my comment are causing this error in 5 to 30 seconds. And it is impossible to load simultaneously files.Because of this error slide is not really multi-user application. Proper implementations of unique number generation: 1.Using "select for update" clause + with chunk number allocation (100 values at one time to reduce number of SQL issued to DB). 2.Using proprietary constructs for DB (sequences, auto-increment). 3.Transaction independent singleton that returns next number. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
