wellllll i don't agree with you :) IMO, two editingcontexts in the same app
should behave exactly like one editingcontext in instance 1 and one
editingcontext in instance 2.
also, it's not at all clear how to even make this method do what you might want
it to do ... as far as i can tell, you would have to basically have to
implement in-memory optimistic locking yourself, and I'm not even sure how to
get access to the snapshot from the other EC in this method, because it's not
the one in committedSnapshot, maybe because it hasn't actually committed, yet,
when this is called? i'm not entirely sure. also, i thought the optimistic lock
field is based on the underlying database snapshot, not on the EC snapshot,
which means that even if you fiddle with merges in your EC, when it comes time
to save EC2, it's still going to use the value committed into the EODatabase
snapshot from EC1, which would result in no optimistic lock.
so here's your challenge ... make this fail with an optimistic lock exception
when EC2 saves (which is what would happen if EC1 was in another instance):
EOEditingContext editingContext0 =
ERXEC.newEditingContext();
editingContext0.lock();
for (int i = 0; i < 100; i++) {
Company c =
Company.createCompany(editingContext0);
c.setName("Company " + i);
}
editingContext0.saveChanges();
Company c0 =
Company.fetchAllCompanies(editingContext0).objectAtIndex(0);
editingContext0.unlock();
EOEditingContext editingContext1 =
ERXEC.newEditingContext();
editingContext1.lock();
Company c1 = c0.localInstanceIn(editingContext1);
EOEditingContext editingContext2 =
ERXEC.newEditingContext();
editingContext2.setDelegate(new TestDelegate());
editingContext2.lock();
Company c2 = c0.localInstanceIn(editingContext2);
System.out.println("Application.Application: ec0 = " +
editingContext0);
System.out.println("Application.Application: ec1 = " +
editingContext1);
System.out.println("Application.Application: ec2 = " +
editingContext2);
System.out.println("Application.Application: " +
c0.name());
System.out.println("Application.Application: " +
c1.name());
System.out.println("Application.Application: " +
c2.name());
System.out.println();
c1.setName("C1 " + System.currentTimeMillis());
System.out.println("C1 updated, not saved.");
System.out.println("Application.Application: " +
c0.name());
System.out.println("Application.Application: " +
c1.name());
System.out.println("Application.Application: " +
c2.name());
System.out.println();
c2.setName("C2 " + System.currentTimeMillis());
System.out.println("C2 updated, not saved.");
System.out.println("Application.Application: " +
c0.name());
System.out.println("Application.Application: " +
c1.name());
System.out.println("Application.Application: " +
c2.name());
System.out.println();
editingContext1.saveChanges();
editingContext1.unlock();
System.out.println("C1 saved.");
System.out.println("Application.Application: " +
c0.name());
System.out.println("Application.Application: " +
c1.name());
System.out.println("Application.Application: " +
c2.name());
System.out.println();
editingContext2.saveChanges();
editingContext2.unlock();
System.out.println("C2 saved.");
System.out.println("Application.Application: " +
c0.name());
System.out.println("Application.Application: " +
c1.name());
System.out.println("Application.Application: " +
c2.name());
}
catch (Throwable t) {
t.printStackTrace();
}
On May 17, 2010, at 5:30 PM, Mark Ritchie wrote:
> Hey!
>
> On 17/May/2010, at 2:18 PM, Theodore Petrosky wrote:
>> so either I am doing something wrong or I don't understand opportunistic
>> locking..
>
> Optimistic locking is for the case when one WOA is optimistic that it's
> changes to a record won't conflict with another WOA's changes to the same
> record.
>
> I'm guessing that you have a single WOA, in which case optimistic locking
> isn't doing what you want. Your EOEditingContext delegate needs to catch the
> notifications for editingContextShouldMergeChangesForObject() and
> editingContextDidMergeChanges() and handle things since the default is to
> silently merge the new over the old.
>
> Apparently we need a wiki page about this since it's been the matter of some
> contention lately. ;-)
> M.
>
> _______________________________________________
> 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/mschrag%40pobox.com
>
> This email sent to msch...@pobox.com
_______________________________________________
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 arch...@mail-archive.com
