|[eclipse.org-architecture-council] [Bug 246840] [discussion] How to use Jobs and ISchedulingRule properly?|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246840 Product/Component: Platform / Runtime --- Comment #2 from Markus Schorn <markus.schorn@xxxxxxxxxxxxx> 2008-09-15 05:39:12 -0400 --- (In reply to comment #1) Your description of how isConflicting() should be implemented is what my intuition also tells me, however it is not documented like this in ISchedulingRule. Your interpretation implies that I cannot write a rule that has a relationship to a rule that I don't have control over (e.g. IResource), whereas the documented API allows for writing a rule that 'contains' an IResource but does not 'conflict' with it. From the documentation it is unclear what consequences such a rule would have. I think it should not be allowed to do that, because it essentally allows to bypass a lock. I understand why rule factories were introduced. However this consturction leads to a significant problem in practice. The main issue in short is that whenever I use API in jobs with my own scheduling rules I cannot be sure that I don't run into the IllegalArgumentException. I would have to check the implementation of the API I am calling and even then I don't know whether the implementation will be kept the same in a future version. Here is an example: 1) When innocently using org.osgi.service.prefs.Preferences.flush() in a job with a scheduling rule of mine I made the mistake not to know that calling this method potentially acquires a lock on resources (this is the case when dealing with project-preferences). 2) As a fix I need to find out (by looking into the implementation of flush()) what rules to obtain: rf.modifyRule(preferenceFile), rf.createRule(preferenceFile.getParent()), rf.createRule(preferenceFile), rf.deleteRule(preferenceFile) 3) There is no API by which I can determine the file used to store the preferences. I need to duplicate this code. 4) There is no guarantee that the rules used within flush() will stay the same in a future version. 5) Even when using the rule-factory, the solution is not 100% reliable, because the rule-factory obtained via ResourcesPlugin.getWorkspace().getRuleFactory() can be different depending on when it is called, so that the rules obtained when creating the job are differnet to the rules obtained when actually running the job. I did not make this up: bug 240888 ==> The consequence for me was to use the IWorkspace rule instead, which is a reasonable solution. However, the problem had to be discovered by a user first, which is the greatest overall issue. -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Back to the top