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: Thu, 20 Dec 2007 23:00:59 -0500
- Thread-topic: Change Notification vs New EditingContext vs ?
Title: Re: Change Notification vs New EditingContext vs ?
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