This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have a MultiDataObject with a static factory method used to create new instances from templates. On the return from: MyDataObject dob; try { dob = (MyDataObject)template.createFromTemplate(moduleFolder, moduleName); if (!dob.isConstructorComplete()) { ERROR CONDITION ........ I receive a reference to the data object that was just created however it is not fully constructed. In order to test this theory, I added some code in the constructor of the data object and set a boolean as the last line of the consturctor. The new isConstructorComplete() method returns false after the createFromTemplate. It appears to me that I am getting a handle to an object that has not completed it's constructor. I am able to reproduce this with regularity on a 2 processor Win2K machine running the Forte4Java build of Jan 31, 2002. If I am getting a handle to a not fully unconstructed object, this seems very wrong to me. Based upon my analysis, this seems to be what is happening. The static method --------- Constructor Portion private boolean constructorComplete = false; public MyDataObject(FileObject pf, MultiFileLoader loader) throws DataObjectExistsException { super(pf, loader); synchronized (this) { this.init(); setConstructorComplete(true); } } private synchronized void setConstructorComplete(boolean value) { constructorComplete = value; } private synchronized boolean isConstructorComplete() { return constructorComplete; } ------------------
Michael, it looks like known problem. The problem usually occurs when the initialization of your dataobject is too long and more than one thread is touching the data object. What are you doing in the constructor of your dataobject?
Your answer raises a number of troubling questions. You state that this a known problem. Known to whom? I see no mention of this either in the javadoc for the createFromTemplate method nor in the general documentation for DataObject. I also see no reference to another Issuezilla bug. Am I wrong in interpreting the the createFromTemplate as being a factory method for data objects? I was under the impression that I had an implicit contract with a constructor (or factory method) of ?Guaranteed initialization with the constructor?. In answer to your question regarding what I am doing in my constructor, I am doing quite a bit. Reading and writing files, perhaps these files reside on remote high latency networks. Is this a problem? Is it documented? I have not followed the whole chain of events but it appears that my DO is being put into a data object pool by one thread picked out of the pool by another, without being given the opportunity to execute the constructor code through to completion. If this is what actually happens, it is a thread hostile situation requiring strict usage guidelines in the javadoc.
I agree this problem is not documented. I am going to add the description to javadoc immediately. The only information about it is in DataObjectPool, but these comments are not part of javadoc: /** A delay to check the notify modified content. It is expected that * in 500ms each constructor can finish, so 500ms after the registration * of object in a toNotify map, it should be ready and initialized. */ private static final int SAFE_NOTIFY_DELAY = 500; .... ---- This is an architecture issue and unfortunatelly it can't be fixed without the large rewrite of data system. It is supposed it will be solved in NetBeans 4.0. The problem can occurs when: - DataObject's constructor takes more than 500ms - Some other thread obtains this dataobject when constructor is still running. It is not possible to prevent other threads from getting the data object when it is already registered (e.g. from compilation, explorer, etc.) Please move the time consuming code from constructor if possible. Hope this description helps.
The better documentation was added to DataObject and MultiDataObject. Changing target milestone -> 4.0
This appears to be an duplicate of: http://www.netbeans.org/issues/show_bug.cgi?id=12853 How did 12853 ever get marked resolved? The last comment in it by Chris Webster indicates that the problem was not fixed. Is there an idiom that can be used in a MultiDataObject constructor that can be used to GUARANTEE thread saftey? Based upon Joe, Chris and my own analysis, I believe not given the current architecture. Is there any way to allow the outermost data object to perform the DataObjectPool registration itself? Once an unconstructed object gets into the pool, it seems all bets are off as regards thread saftey.
I believe that issue 12853 is resolved. If the DataObject constructor does not take too long (more than 500ms) everything should work. The current architecture does not allow good solution of this problem. This will be solved with the datasystem rewrite. Michael, your solution to allow the object to notify the pool that it is finished worth attention. I suggest add to modify MultiDataObject in following way: 1. add new constructor MultiDataObject (FileObject fo, MultiFileLoader loader, boolean willNotifyWhenCreated) 2. add a method protected final void notifyCreated () Michael would use the constructor with 3rd argument == true and when his constructor finishes he would call notifyCreated (). The DataObjectPool would treat such data objects in a special way and stop doing all the magic it does currently. Still this is not excelent solution, but in current architecture we can hardly hope in better.
In my opinion all data objects should be created using the new constructor proposal. If the data objects are created via a loader, the invoker of createMultiDataObject method would have the responsibility of the create notification. This would alleviate the design problem where a DataObjectExists exception is thrown from the constructor of DataObject.
Requesting a waiver for FFJ 4.0 (Orion). Architectural problem. Cannot be fixed reliably for Orion.
Waiver approved.
This bug is reported in version <= 3.4dev and still not fixed. Due to that it forbids the release candidate for 3.4 to be promoted. Are you aware of that and are you intensively working on the fix? If not, you should consider some corrective action.
I agree with the waiver
Docs agrees with wavers. I am leaving Patrick on the CC for his records.
I am sorry but this will not be fixed in 3.5. Changing target milestone to 4.0.
Changed owner David S. -> David K.
Changing TM to "FUTURE" which is more appropriate, because at the moment I do not plan to fix this issue for next version. Let me know if you disagree. I'm open to change the plan.
I think the atomicity of "DataObject"s or there replacements and the recognition and construction should be requirements for the new DataSystems. A DataObject is not locatable until 1. it is fully constructed 2. the associated files have been fully constructed. This functionality should be provided via the underlying infrastructure.
When I see a change like this what I really want to know is 'what it means'. Does this mean that someone has decided there will be no Data Systems rewrite in 4.0? Or there will be a rewrite but this bug won't be addressed? Does this mean that there will be a 4.0 without Projects? Or will there be another NB version before Projects?
Created attachment 10198 [details] Solution to the DataObject constructor problem with a test
I'd like to present a solution to all the DataObject constructor problems. It solves the need for knowing when a constructor is finished by forcing every code to use DataObject.find (...); or a similar method - this is the behaviour that 99.9% of all code does. So I think it worths to try. The only reason why this has not been implemnted few years ago was the 0.1% of usages that could be broken and we were so possesed by compatiblity that we rather lived with broken code than to change it incompatibly. So what do you think?
Andrew, what this means? That I do not plan to fix this issue for 4.0 (ie. next version) in current DataSystems. That's why I set TargetMilestone to "future". Nothing more. I changed TM intentionally to learn *from you* more about this issue and either put it into my plans for next version or not. The rewrite of the DS is still planned and all problems of the current system (including this one) have to be addressed. However it is not clear when it will be finished and into which version it will get. Btw. I'm currently working on extracting settings capabilities of current datasystem (InstanceDO, XMLDO) into separate library (Registry API). Then I would like to continue where DavidStrupl stopped with FileSystem Extensions. So from my point of view I do not want to waste my time fixing issues in library which will be discarded. I would rather invest all my time into the new DS. But on the other hand I know that this issue is serious for you and so I need to know whether I should rather fix it. On the other hand if you switch to new projects you will not need this anymore. But I do not know your plans. Too many unknowns. :-) We do not have to resolve this right now. I just wanted to express how I'm thinking about this issue and synchronize it with your expectations. And Yarda already attached the patch! It might break something but at least we already have a solution. Because of possible breakage I would wait with the commit till you clearly state that you want me to fix this and that your next version will still be using current DataSystems. Without that would be fixing useless and possibly only destabilize other API clients. Thanx.
Thanks for the clarification. Now I understand what you mean :-) We are committed to Projects, barring major disaster or high level management stupidity. So I think you should not bother with this bug and concentrate on moving forward as you suggest. Chris do you agree?
The current design is reliant on projects at this point attempting to implement some of the proposed changes without projects would either have a significant negative impact on schedule or the feature itself. Please work on the new DataSystems.
I am confused. Where is a list of what we are planning for 4.0? If there is a thread safe alternative to DataObjects slated to be released in conjunction with projects, then that effectively eliminates the issue for me. Note that this issue has festered since June 2001 (see IZ 12583). I think it is reasonable to request a thread safe version of data systems for 4.0. This does not necessiarly entail fixing the current data systems, we will be modifying our S1S code to work with the new projects/DS implementations anyway. Doing this work in the new code base is preferable. What is confising about this dialog is that we dont know which DS we will be basing the next release of S1S on.
"Where is a list of what we are planning for 4.0?" - I afraid there is no list at the moment. I was only evaluating all the issues assigned to me in issuezilla and was updating their state to be more precise. The best source of information about what is happening in core can be found at <http://core.netbeans.org/>. "If there is a thread safe alternative to DataObjects slated to be released in conjunction with projects, then that effectively eliminates the issue for me." - the new projects is this alternative. Andrew knows more from his visit in Prague.
Nobody can get a grip on unconstructed data object since issue 33469 has been implemented.
closed