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]
