Well, you're welcome. :) Also, as for the double-checked locking working, there is a reasonably good article on wikipedia: http://en.wikipedia.org/wiki/Double-checked_lockingthat seems to imply that in Java 5 it can work with volatile. However, I read somewhere else that the new constructs for volatile may mean that you won't see any better performance than you would if you just synchronized the method (but I don't remember where I read that).
On 11/15/06, Nick Westgate <[EMAIL PROTECTED]> wrote:
Canonical use of ReentrantLock here wouldn't be any better than synchronize(this), would it? I'm wondering what you have in mind. Anyway, my company is only just starting to look at using Java 5, so I'm not really familiar with the concurrent classes yet. Jeff: Thanks for your testing. I was finally going to put 3.04 in production after our next round of development! It would be handy if something like double-checked locking was guaranteed to work. (I think it's valid in Python.) Cheers, Nick. Jesse Kuhnert wrote: > You could always just use the apis provided by backport-util-concurrent as > well....It makes it almost trivial to do these tasks, all without being > retarded about thread management. (as would be the default behavior > exhibited when using the "synchronized" keyword ) > > On 11/14/06, Jeff Poetker <[EMAIL PROTECTED]> wrote: >> >> Ok... Well, I'm not sure I'm ready to go there just yet... I did want to >> send an update to whom it may concern... >> >> I worked with our load test environment today, and was able to reproduce >> my >> problem fairly easily. We ran a set of about 20 virtual users in a script >> that would have all 20 request a page at the same time, wait for all >> 20 to >> get responses, then send all 20 at another page. All, on a freshly >> started >> server, with no page objects pooled yet. >> >> The repetitive method errors started showing up almost immediately with >> the >> 3.0.4 code. >> >> So, next I overloaded the getter in the engine that returns the >> DefaultComponentClassEnhancer, and had it return my own >> ComponentClassEnhancer. My version works the way 3.0.3 did, with the >> double-checked locking code. (I know this code is not guaranteed to work, >> but because we hadn't seen this problem before, it seemed like it had >> been >> working for us). >> >> I ran the same test with the double-checked locking code. No problems. >> (FYI >> - I was testing against a dual Xeon (NetBurst, not Core) server and the >> JRockit VM on RedHat Linux). >> >> Ok, so, this "fixes" my problem, but I've been studying up on this >> double-checked locking thing, and get that it isn't really safe to assume >> it >> will work... So, I tried doing the only thing that most of the articles I >> read said you could do - synchronize the whole thing. So I re-implemented >> my >> custom ComponentClassEnhancer to syncrhonize the method in question... >> >> Of course, this also works... It also made my simple 20 user test take 2 >> minutes longer. :( >> >> My test of course was a worst case, hitting new pages with nothing >> pooled. >> Tomorrow I'm going to try both solutions with a more realistic load, and >> find out if the synchronization solution is really going to hurt us or >> not. >> >> >> On 11/13/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: >> > >> > Yep, a much more efficient means of doing it would be to use >> > http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ . It seems >> like >> > this is crossing over on the annotation exceptions being thrown when >> > caching >> > is disabled as well. (though maybe the solution for t4 won't be the >> same >> > as >> > t3 since t4 is based around hivemind. ) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
