Interesting approach.
If the only method available to getting the nested context from the session is always going to revert the changes on it, why not just do the following?
public EOEditingContext getNestedEC() {
return ERXEC.newEditingContext( defaultEditingContext() );
}
That way (as Ken mentioned) if the context is not saved in the editing page using it then it's simply garbage collected.
Good suggestion. I tried it, but ended up with the same problem.
Also my understand is that ERXEC has automatic locking, so I'm not sure why you're attempting to lock/unlock in your session awake/sleep methods. That may be overriding some normal behaviour. Or have you turned off it's automatic locking?
My understanding regarding ERXEC is the same as yours, and even reading through the Project Wonder code, I get the strong impression that it should work everywhere. But if I comment out my locking code and add the following to my application constructor:
NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupEnterpriseObjects |
NSLog.DebugGroupMultithreading);
I get output everywhere that I am using an editing context without a lock. So I'm a little afraid to leave it that way.
-----------------Session.java----------------
Within my "Edit" page, I have an instance variable that I call _nestedEC which gets initialized by calling session.getAndRevertNestedEC();
I can create EOs, insert them into _nestedEC, save _nestedEC, save session.defaultEditingContext(), and everything is great. If I then immediately delete the newly saved and created EOs:
_nestedEC.deleteObject(objectToDelete);
_nestedEC.saveChanges();
ec.saveChanges();
Is this being done within the same edit page? i.e., there's some method to apply changes which displays the same page again and then there's an action that can be hit which allows the user to delete the objects?
Yes, exactly. The main point of the edit page is to allow the user to create a catalog item in a store which represents a bundle of other items, but at a discounted price if they are bundled together. The overall catalog item gets created correctly, but the section of the page which allows you to add/remove "bundled" items is where the issue is. For some reason, adding is not a problem, and removing items when you first come into the page is not a problem, but if you add items (which reloads the page) and then delete items that you have just created, it might do fine on the first one or two that you create/delete, but somewhere along the way it will throw an exception that complains that it doesn't have a snapshot for the item you are deleting:
java.lang.IllegalStateException: recordDeleteForObject: com.webobjects.eoaccess.EODatabaseContext com.webobjects.eoaccess.EODatabaseContext@a0fcdc failed to find a snapshot for EO with Global ID:_EOIntegralKeyGlobalID[KitQuantity (java.lang.Integer)1234] that has been deleted from er.extensions.ERXECer.extensions.ERXEC@419cf7. Cannot delete an object that has not been fetched from the database
Is it possible that because each edit page always receives the same nested context from the session rather than a unique instance for that page that the user has opened another edit window within the same session and thus blown away the nested ec's current state?
I think that technique is problematic in either case.
It is possible. I've never tried creating the nested EC at the page level because of information contained here:
How/where do you lock nested editing contexts that you create at the component level?
Furthermore, if I examine the state of the snapshots, I can see that they get in all kinds of terrible shape as I add/delete things in the nested EC and save changes. I should clarify one point. _nestedEC's snapshots of the objects seem fine, but the default editing context's snapshots just go to hell in no time if I don't use EODatabase.disableSnapshotRefCounting() in my application's constructor. Do you do this in your applications?
No.
Cool. Well, it certainly seems to be working correctly for a few people at least, so there must be something I'm doing that's throwing if off. I'll keep trying things that people suggest as long as the suggestions keep coming in...
Mark