Re: Locking exceptions and more
Re: Locking exceptions and more
- Subject: Re: Locking exceptions and more
- From: Art Isbell <email@hidden>
- Date: Tue, 22 Jul 2003 10:50:46 -1000
On Monday, July 21, 2003, at 11:05 PM, Merul Patel wrote:
I'm playing around with some modifications to the message board
example in Ravi Mendis' book, where all posts are fetched into a
SharedEditingContext. The "message" content of each post is locked in
EOModeller to ensure optimistic locking is used.
In order to edit a particular message, I've implemented a directAction
where the message is localised using
EOUtilities.localInstanceOfObject() into the
session().defaultEditingContext()
One of the features of EOSharedEditingContext
(http://developer.apple.com/documentation/WebObjects/WebObjects_4.5/
System/Documentation/Developer/WebObjects/DeltaDoc/EOF.html#CBGCHAIA)
is that shared objects may be related to objects in other editing
contexts without creating local instances.
and then passed to an editing WOComponent by invoking takeValueForKey
on the localised post:
Number postID = request().numericFormValueForKey("postID", new
NSNumberFormatter());
EOSharedEditingContext SEC =
EOSharedEditingContext.defaultSharedEditingContext();
EOEnterpriseObject _post =
EOUtilities.objectWithPrimaryKeyValue(SEC, "Post", postID);
Another EOSharedEditingContext feature is that when one entity with
shared objects is explicitly fetched, all other entities with shared
objects in the same eomodel will automatically be fetched. The idea is
that all shared objects will be fetched once during the life of the
process. So for a Web app, fetching all shared objects when the
instance is launched will populate the shared editing context before
any sessions are created. This can be triggered by fetching one entity
into the shared editing context in Application's constructor. This
entity should not be configured as shared in the eomodel to avoid its
being fetched twice.
By invoking EOUtilities.objectWithPrimaryKeyValue(), you are likely
causing a refetch of the same Post objects that have already been
fetched thus nullifying this shared editing context feature (check the
SQL generated by setting the launch argument "-EOAdaptorDebugEnabled
true").
Instead, access the objects already fetched into the shared editing
context by sending the shared editing context an
objectsByEntityNameAndFetchSpecificationName() or objectsByEntityName()
message. This will avoid an unnecessary DB access. Then you can
filter the returned objects using
EOQualifier.filteredArrayWithQualifier().
Changes to the post are submitted in a form, and the editing component
invokes saveChanges() on the session().defaultEditingContext() to save
changes.
This is probably failing because shared objects cannot be updated in
an editing context whose sharedEditingContext isn't null (this is true
for WOSession's defaultEditingContext). The EOSharedEditingContext
class documentation describes how to update a shared object indirectly.
You need to create a new editing context with its sharedEditingContext
set to null. Then in this editing context, create a local instance of
the object you want to update, update it, and save it. The
documentation states that the shared editing context should by notified
that one of its objects has been updated and will refault it so the
updated object will be refetched automatically when next accessed.
However, this has not worked reliably for me, possibly because I may
not have configured something correctly. Instead, I've explicitly
refetched the entity whose object was updated.
For debugging purposes I print the submitted post to System.out to
ensure the amended values have been captured correctly:
System.out.println("Post edit was " + post);
session().defaultEditingContext().saveChanges();
The post displays correctly in the editing page, but sometimes the
changes are not captured when I click on save?!
All saveChanges() messages sent to any editing context should be in a
try-catch block. I suspect that saveChanges() is throwing an exception
("can't update a shared object") that you aren't catching. This
exception is preventing the save from succeeding.
Bizarrely, simply rebuilding the application and running it again
fixes this problem, but then I end up running into locking exceptions
as follows.
However I had presumed that, since the edited message was displayed
correctly in the message listing, the sharedEditingContext() had been
notified of the change to the relevant post and would invalidate and
refault the post and it's snapshot.
The object has been changed locally, but the changes aren't being
saved to the DB due to the uncaught exception. I suspect that this is
causing the subsequent exception as well.
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.