Corin Moss dijo:
Hiya,
JCS certainly has an implementation of a r/w lock:
http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/utils/locking/
ReadWriteLock.html
While reviewing the code at line 111 is interesting to me why wait full 2
seconds on it. It is a lot of time!
Based on my
Carsten Ziegeler wrote:
Corin Moss wrote:
JCS certainly has an implementation of a r/w lock:
http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/util
s/locking/
ReadWriteLock.html
The indexed disk cache certainly uses it, as I suspect does
any other cache which needs such a thing. So I
Corin Moss dijo:
Hi Guys,
When I first started looking at the persistent store I mentioned the
read/write locks contained within AbstractReadWriteStore as a potential
issue. Under load test with the new JCS based store I'm still seeing
really high iowait usage after about 10-12 hours
The A-R-W store is just a dump default implementation. The old stores in
Cocoon/Avalon weren't synchronized properly, so they sometimes suffered
from threading issues.
A first easy-to-do solution was the A-R-W store with using the locks. Now,
I haven't looked into JCS, but I guess they are doing
p.m.
To: [EMAIL PROTECTED]
Subject: RE: Locks within AbstractReadWriteStore
The A-R-W store is just a dump default implementation. The old stores in
Cocoon/Avalon weren't synchronized properly, so they sometimes suffered
from threading issues.
A first easy-to-do solution was the A-R-W store
Corin Moss wrote:
JCS certainly has an implementation of a r/w lock:
http://jakarta.apache.org/turbine/jcs/xref/org/apache/jcs/util
s/locking/
ReadWriteLock.html
The indexed disk cache certainly uses it, as I suspect does
any other cache which needs such a thing. So I guess we
