1. We're thinking that the only way to fix this is to start using
Project Wonder and the ERXRemoteSynchronizer for change
notifications. I'm still a little concerned that it won't help our
specific case.
(here is the scary scenario)
We get an NSArray of EO's from a relationship, and are enumerating
over them.
A change notification comes in relating to one of the EO's in the
array (it's actually been deleted by another user on another
instance, which happens all the time)
When the object in question is re-fetched from the database, it
turns out to be deleted(!) and is then null, and is then very bad
for us.
Will ERXRemoteSynchronizer handle this is some nice way, or will the
object still resolve to null in the middle of the enumeration? (if
it's still null, we need to think of some other solution...)
(so if it's still going to get nulled in the middle of the
Enumeration - what the heck can we do?)
This is from ERXObjectStoreCoordinatorSynchronizer's testcase:
NSArray<Employee> holdingOnToEmployees = company_osc2.employees();
assertEquals(2, holdingOnToEmployees.count());
for (Employee employee : holdingOnToEmployees) {
assertNotNull(employee);
assertNotNull(employee.name());
}
NSArray<Employee> holdingOnToUntouchedEmployees =
company_osc2.employees();
assertEquals(2, holdingOnToUntouchedEmployees.count());
// Delete Employee1 in OSC1 and Save
editingContext_osc1.deleteObject(employee1_osc1);
editingContext_osc1.saveChanges();
sleep();
// Test that the deleted object is technically still in our EC
assertEquals(2, holdingOnToEmployees.count());
for (Employee employee : holdingOnToEmployees) {
assertNotNull(employee);
assertNotNull(employee.name());
}
// Test that the deleted object is technically still in our EC
assertEquals(2, holdingOnToUntouchedEmployees.count());
for (Employee employee : holdingOnToUntouchedEmployees) {
assertNotNull(employee);
assertNotNull(employee.name());
}
for (Employee employee : holdingOnToEmployees) {
employee.setName(employee.name() + " Modified");
}
try {
editingContext_osc2.saveChanges();
throw new AssertionFailedError("This should have failed.");
}
catch (EOGeneralAdaptorException e) {
// expected
}
// Fetch and check employees for Company1 in OSC1
assertContainsExactlyEOs(new NSArray<Employee>(new Employee[]
{ employee2_osc1 }), company_osc1.employees());
// Fetch and check employees for Company1 in OSC2
assertContainsExactlyEOs(new NSArray<Employee>(new Employee[]
{ employee2_osc1 }), company_osc2.employees());
So once it's already fetched. you hold a fetched reference to the EO.
When the object is deleted from object store 1, it's still in your
fetched array (and it's verifying it's non-null and contains data).
If, however, you fetch the employees() array AGAIN, it is now gone
from the array. I believe this is testing your scenario. Now, if you
try to MESS with that EO (as in the example), you're going to get an
adaptor exception ("updateValuesInRowDescribedByQualifier --
com.webobjects.jdbcadaptor.JDBCChannel method failed to update row in
database") because the original EO is gone, but I suspect this is a
little easier to deal with than your random null.
2. We ditched JGroups in favor of JMS as our message transport so we
can use the built-in JMS providers in our J2EE deploys. (which is
much nicer)
We're thinking that we can write an interface for the constructor of
ERXRemoteSynchronizer so that it can use a JGroups or JMS provider
transparently.
In your reply above you said that JMS will not work, ever.
Sorry, I was specifically referring to the JMS change notifier in
Wonder. There's nothing intrinsically wrong with delivering change
notifications over JMS. There is no reason you couldn't implement a
JMS subclass of ERXRemoteSynchronizer (you can look at the jgroups
code -- it's pretty small).
Can you please expand on this? I was under the impression that JMS
is used and relied upon heavily in the J2EE world.
Will JMS + ERXRemoteSynchronizer be OK? (which I would think is the
case, as JMS just delivers messages, the Wonder framework decides
what to do about the message).
Yes. That is correct.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
