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=37356>. 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=37356 ------- Additional Comments From [EMAIL PROTECTED] 2006-03-10 16:17 ------- (In reply to comment #24) > Proposed patch: > > in org.apache.catalina.session.StandardSession > line 284 (tomcat 5.0.28) > > /** > * The access count for this session. > */ > protected transient int accessCount = 0; > > has to be replaced by > > /** > * The access count for this session. > */ > protected volatile transient int accessCount = 0; > > Explanation: > The expression accessCount++ is not thread-safe because each thread may hold a > local copy of the variable which does not have to be synchronized with main > memory immediately. > The volatile keyword forces this synchronization. > > See the discussion on > http://forum.java.sun.com/thread.jspa?threadID=604831&start=30&tstart=0 > > [quote] > 2) Local vs. main mem: Threads have--or can have--their own local copies of > shared variables. When T1 writes a value to a variable, if the variable is not > volatile and there's no syncing, that new value may live only in T1's local > copy > and may never get written to main mem, which means other threads may never see > that new value. Entering and leaving sync blocks forces a reconciliation > between > the thread's local memory and main mem. Declaring a variable volatile forces > every read and write of that variable to go to main mem. > [end quote] > > Another solution would be to synchronize the code segments. > > I have to apologize for my claim that ++ and -- were atomic for int > datatypes. > This seems to be only true for single-CPU systems (without hyperThreading). Volatile may not be the best idea. From the article: http://cephas.net/blog/2003/02/17/using_the_volatile_keyword_in_java.html "Careful, volatile is ignored or at least not implemented properly on many common JVM's, including (last time I checked) Sun's JVM 1.3.1 for Windows. There was an article on DDJ that could demonstrate this even on single-processor machines..." And from the article: http://www.javaperformancetuning.com/tips/volatile.shtml "Note however that volatile has been incompletely implemented in most JVMs. Using volatile may not help to achieve the results you desire (yes this is a JVM bug, but its been low priority until recently). " Our environment: We are only seeing this issue for sure on one machine, which is a 4 way (with HT--8 virtual CPU's) box. We see the issue pretty frequently occur there... maybe 20-100 times a day for a total of 2,000-4,000 total sessions. Also, this environment is NOT 64-bit. These are 32-bit HT Xeons. They are running the Sun 1.4.2_06 or the 1.4.2_08 JDK... So we know this issue occurs on 32 bit systems as well. -- 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]
