We’re reviewing.
I guess it comes down to what level is the
expected “api” in an area where there is no declared api. For
our part, we should be able to confirm that we use ModuleStructuralModel or
above, and aren’t directly calling the code it’s trying to protect.
Don’t know if WTP components and
other adopters can verify that they are not calling this “protected”
logic directly. Seems like a reasonable expectation that they shouldn’t.
-Ted
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuck Bridgham
Sent: Monday, April 03, 2006 8:20
AM
To: General discussion of
project-wide or architectural issues.
Subject: Re: [wtp-dev] Request PMC
approval for 130994 - please review deadlockissues
Hi David,
Well
this is a problem with all of our code in WTP, we don't have a general locking
policy, and I am trying to solve this particular use case.
I
want more eyes on it from the BEA side, since they have the reproducible scenario.
I
kept the object locks just for that case where all clients are not using
scheduling rules. I believe this patch will solve the problem BEA was
encountering,
but
I don't claim it can fix all locking issues, and until WTP/eclipse has a
general policy, this is a very hard problem.
-
Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle
Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
David M
Williams/Raleigh/IBM@IBMUS
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
04/02/2006 11:01 PM
Please
respond to
"General discussion of project-wide or architectural issues."
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [wtp-dev] Request PMC approval for 130994
- please review deadlock issues
|
|
I would appreciate further review of this fix.
As you state, its follows a pattern of
acquire SchedulingRule
synchronized (some object)
{meaty stuff}
release ScheduleingRule
I think this is still deadlock prone, unless *all* clients use exact same
pattern.
If, for example, somewhere else, only synchronized is used, AND ends up calling
back to this code, then I think deadlock will occur.
Is it known (or, at least documented) that this is the pattern all clients
should use?
My guess is not, and that's why you are using synchronized block to begin with.
Or, perhaps, synchronized part is not needed at all? And could do all with
scheduleing rules?
I must confess, this was from my quick reivew of the patch ... so I may be
mis-reading it, or
these issues may be well (better!) understood,
but just thought I'd request the education for myself.
Thanks,
Chuck
Bridgham/Raleigh/IBM@IBMUS
Sent by: wtp-dev-bounces@xxxxxxxxxxx
03/30/2006 12:00 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[wtp-dev] Request PMC approval for 130994
|
|
Have fix that first acquires lock based on scheduling rules, then uses the
object monitor locks. finally it releases the lock through the JobManager.
This will avoid deadlocks with other processes that also use scheduling rules.
Tested locally
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle
Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev