Re: Locking problem
Re: Locking problem
- Subject: Re: Locking problem
- From: Florijan Stamenkovic <email@hidden>
- Date: Mon, 13 Oct 2008 23:41:47 -0400
So, assuming I didn't do any major screw-ups when doing this, it
should work. However, what I'm currently doing with JC might produce
an even "heavier" load then a web scenario. Not in terms of volumes
for sure, but in terms of how rapidly calls from different threads
are made to a single ec. So yeah, this might make sense. Especially
what you say about "weird race conditions". A combination between
Eclipse's debugging and having log4j's detailed logging turned on for
the EC made it stop crashing, almost always. But that does not solve
the issue...
So, bottom line, anyone knowing EOF really in-depth, is it possible
to somehow make a generically locking EC that multiple going-wild
Threads can't screw up? Even if it adversely affects performance
somewhat. Or do I have to load it all to a single thread? That is
what JC normally does, as far as I know, it is all done on AWT's
event dispatch thread.
Also, when I first switched to the autoLocking EC I still had manual
locking being performed for every operation I did manually on the EC.
I got crashes regardless..
Thanks,
F
On Oct 13, 2008, at 20:14, Mike Schrag wrote:
Yep, sorry -- you're right ... Lock coalescing is the one that
depends on the RR loop. That said, I definitely ran into cases
where auto-locking alone was not enough (at least on the web ...
maybe it's less of an issue with JC). What would happen is that
you'd have a series of, say, 5 operations that were logically a
single transaction, but would be 5 individual lock-unlock
autolocks, and there would be changes to the snapshot state
inbetween calls that would cause some weird race conditions. This
is actually why I decided to do the lock coalescing stuff in
Wonder, which seemed to clear up the issues. But not having done
JC, maybe this is less of an issue. It only appeared under higher-
than-"normal" load.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden