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 PROTECTED]> 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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/simon_mclean%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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%40mdimension.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
