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
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."
"General discussion of project-wide
or architectural issues." <wtp-dev@xxxxxxxxxxx>
[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
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Phone: 919-254-1848 (T/L: 444)_______________________________________________
wtp-dev mailing list