| Race condition on save [message #1385009] |
Tue, 03 June 2014 15:30  |
 Hernan Gonzalez
Messages: 188
Registered: October 2010
Location: Buenos Aires, Argentina |
Senior Member |
|
|
I've spent too much time debugging this ugly problem.
My symptoms: I modified my diagram in the editor (dirty mark appears), save it (dirty mark goes out), switch to another editor instance, return to the previous... and the original editor appeared marked as dirty; actually, it isn't, and the save is disabled - worst, the problem is not fully reproducible, it happens sometimes (strangely enough, more in my Linux VM than in my Windows host). And when debuggin I see lot of strange things happening during the editor reactivation (a handleResourceChanged is triggered, which triggers a resource unload so that a refresh reloads it, but while the resource is unloaded there are quite a few of isDirty() calls, which get rather confused - they don't expect to be called when there is no accesible diagram... ) A nightmare.
Anyway. I'm still not sure if all that strange things points to some hidden programming issues inside my code or Graphiti code, but I finally discovered that the root problem occured earlier, and it was simpler.
The problem is in DomainModelWorkspaceSynchronizerDelegate.handleResourceChanged()
which is called by Eclipse when it detects changes in the resources (at the Eclipse level, not at the EMF domain level - typically, changed files). Graphiti current logic is to compare the file timestamp with the resource timestamp and set resourceChanged=true if and only if these don't coincide.
There is a potential (and, in my case actual) race condition here. The resource timestamp is set after the file has been writen and closed.
Can we be sure that the Eclipse notification of changed file will reach us AFTER the timestamp on the resource has been set? Apparently we can't. And apparently, for me it happened earlier - and this messed up everything. Empirically, I found that adding a to DomainModelWorkspaceSynchronizerDelegate.handleResourceChanged() a mere Thread.sleep(5) before resource.getTimeStamp() fixed the problem.
Of course, I'm not very happy with this solution  but anyway, I think something should be done. Is anyone aware of some related issue? Should I fill a bug?
[Updated on: Tue, 03 June 2014 15:33] Report message to a moderator |
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.24719 seconds
] 
Search
Help
Register
Login
Home
