Hi Lachlan,
Thanks for responding.
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
[EMAIL PROTECTED] failed to find a
snapshot for EO with Global ID:_EOIntegralKeyGlobalID[KitQuantity
(java.lang.Integer)1234] that has been deleted from
[EMAIL PROTECTED] 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:
http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/Using_EOF/
Context_and_Database_Locking
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]