Re: Change Notification vs New EditingContext vs ?
Re: Change Notification vs New EditingContext vs ?
- Subject: Re: Change Notification vs New EditingContext vs ?
- From: Dov Rosenberg <email@hidden>
- Date: Fri, 21 Dec 2007 22:54:08 -0500
- Thread-topic: Change Notification vs New EditingContext vs ?
Title: Re: Change Notification vs New EditingContext vs ?
I am not sure what the ERJGroupsSync code buys me over JMS (I will take a look though). I don’t think our biggest problem is getting the notification. I think our biggest issue is dealing with freshening up our data once we get the notification. It seems that since our app is pretty busy the act of invalidating the objects seems to cause other sessions to lock up. Is that because we are not locking the ObjectStoreCoordinator?
Dov
On 12/20/07 11:14 PM, "Mike Schrag" <email@hidden> wrote:
I'm totally biased here, but I agree with Simon -- You should definitely check out ERJGroupsSync ... This is an incredibly hard problem to get right, and I was only ever able to do it properly when I ultimately hooked into EODatabaseContext directly to be able to get cache change notifications. In almost any other way (I went through about 3 or 4 implementations before settling on the current one), you are bound to end up with dead locks, lost updates (like not receiving updates of the inverse relationship being updated), or really expensive change tracking. That you have that lock commented out gives me a HUGE case of the willies. I spent several weeks of development on this problem .. I would say it's the most complicated work that I've done on WO, in fact, mainly because things are so fragile at this level. One slip of a lock or a misunderstanding of calling order, and horrible things happen. I won't claim that ERJG is without bugs, but I can assure you this code sample you're showing is really scary :)
ms
On Dec 20, 2007, at 11:00 PM, Dov Rosenberg wrote:
The big problem we are facing on the change notification is the object invalidation within EOF. JMS seems capable of getting the messages where they need to be, its just we are getting NSRecursiveLocks when trying to invalidate the individual objects. We do something like the following (we only send the globalids in the JMS message):
public void run() {
NSMutableSet ids = IMGlobalIDsQueue.getIdsAndResetQueue();
int count = 0;
if (ids != null && ids.count() > 0) {
EOObjectStoreCoordinator coordinator = EOObjectStoreCoordinator.defaultCoordinator();
//coordinator.lock();
count = ids.count();
try {
coordinator.invalidateObjectsWithGlobalIDs(ids.allObjects());
} finally {
//coordinator.unlock();
}
}
}
We build up a queue of the incoming messages and process them with a timer thread with the above code. If we uncomment the coordinator.lock()/unlock() methods bad things happen very quickly. The timer is a singleton class so there should only be a single timer per application/object store coordinator. It seems the lock is happening when a new EditingContext is being created by either a session or via new EOEditingContext().
Dov Rosenberg
On 12/20/07 10:31 PM, "Simon McLean" <email@hidden> wrote:
We used the JMS stuff a while back and had similar problems. We now use ERJGroups instead and have found it to be much more scaleable, albeit a little memory hungry. I would definitely give it a shot before changing any code as it's pretty much a drop-in replacement for the JMS stuff.
Simon
On 21 Dec 2007, at 03:01, Dov Rosenberg wrote:
We have been using a JMS based change notification framework (based on the Project Wonder code) and have started to notice more deadlocks and performance problems under higher load and more servers in the network. I think we have decided that an external change notification framework is just not going to be scalable enough for our needs.
We have been throwing around various strategies but I wanted to vet them to the greater WO community for assessment. Any feedback is appreciated.
Application Profile:
Our application is deployed as a servlet using a WAR file that gets expanded by the container (Tomcat 5.5). The app is currently built using WO 5.3 but we are in the process of converting it to WO 5.4. Our application is typically deployed in multiple tomcat instances across 1 or more machines in a network. We have an administration console, a web client (using EOF based custom JSP tag libs that we created), and a set of EOF based Apache Axis web services. The web client is primarily read only and makes extensive use of the SharedEditingContext. The web services client is basically stateless. The mgmt console is a typical WO/EOF application that uses the defaultEditingContext extensively. We have borrowed some Project Wonder components and adapted them to our needs but have not implemented the whole Project Wonder set of frameworks. Administration console users generate content that the web client and web services clients interact with.
Option 1:
Replace the session based defaultEditingContext in the mgmt console and create a new EC each time one is needed. Perhaps using the ERXEC instead of a regular EC. This would still leave us with the SharedEditingContext to deal with in the web app. The web app needs to see fresh data when it occurs, but short of replacing the shared EC with a new EC each time and doing a lot more DB fetches I am not sure how to maintain adequate performance.
Option 2:
Replace the standard EC and associated ObjectStoreCoordinator stuff with Project Wonder components (is there a Wonder SharedEditingContext?)
Option 3:
Come up with another strategy to deal with multi instance data synchronization.
Dov Rosenberg
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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