Re: Snapshot problems - Solved, sort of
Re: Snapshot problems - Solved, sort of
- Subject: Re: Snapshot problems - Solved, sort of
- From: Lachlan Deck <email@hidden>
- Date: Sun, 22 Apr 2007 12:58:21 +1000
Hi Steve,
On 22/04/2007, at 12:06 PM, Steven Mark McCraw wrote:
I'm not sure why this would happen. If you destroy the child
editing context without saving to the parent, you should not have
anything half finished anywhere.
I wasn't very clear here. What I meant to say was that I'm
attempting to use nested editing context as a means of preventing
people from setting a few attributes of an EO, not committing,
going to another totally unrelated page, and committing the
previous changes from before when they save. Nested editing
contexts seem to be one means of accomplishing this.
Indeed.
I'm having all kinds of difficulties with them, so I'm looking for
other alternatives. One other alternative would be to define a
dictionary or a bunch of local variables per page to bind to, and
only copying those into an EO when you are ready to commit.
That would be painful.
Since the thing I've been doing for years (not inserting the
object) has been getting so much bad press lately, and the
suggested alternative (nested ECs) is causing me to lose tons of
sleep, and the other alternative I can think of seems like a lot of
boring work, I'm asking if there are other alternatives or at least
if others are having the same experiences I am having with nested ECs.
I've not seen these problems either. But I've not deployed with WO
5.3 (but still 5.2.4).
And if so, is no one else seeing these kinds of ridiculous
corrupted snapshot problems?
Honestly, I don't. Can you give us some examples of your usage of
nested contexts and why you end up with half finished data?
As explained above, I don't end up with half finished data, but I
do end up with corrupted snapshots in EODatabase which cause
exceptions when I try to do fairly trivial things. Here is the
setup... I have a nested editing context reference in session
(nested in the session's default editing context):
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.
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?
-----------------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?
I will eventually randomly get something that looks like this:
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.
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.
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden