We have been using a modified version of the ERChangeNotificationJMS framework for a couple of years with pretty good success. We have recently started running into problems as we have been scaling our app to larger sets of data. We are using OpenJMS and have experienced some unstable behaviors - usually they can be fixed by rebuilding the embedded derby database. If you use Oracle it seems to be much more stable.
We fixed our scalability issues on the JMS change notification by creating a queue where all of the change notification messages come into. By having a singleton process the message queue we were not continually invalidating objects over and over as messages came in from all over the place. Prior to having the message queue the change notification code was executed everytime a JMS message was sent. When we started scaling to 100's of concurrent authors on multiple load balanced servers - messages were flying all over the place. Our modified JMS changenotification code only passes along EOGlobalIDs instead of the whole snapshot. After receiving the message we invalidate each individual object instead of all objects. The queue gets processed on a timed basis (our default is 30 seconds) and has dramatically improved our overall performance. Our queue is setup such that we only have 1 entry per global id, all we care about is the fact that it changed and our local copy should be invalidated - we don't care how often it is being changed. Hope this helps -- Dov Rosenberg Inquira Knowledge Management Experts http://www.inquira.com On 10/23/07 11:31 AM, "Anjo Krank" <[EMAIL PROTECTED]> wrote: > OpenJMS is pretty flaky. I'd recommend one of the other Synchronizers > (ERXSimpleMutliCast or ERJGroups) > > Cheers, Anjo > > Am 23.10.2007 um 17:20 schrieb Gino Pacitti: > >> Hi All >> >> Can I use the ERChangeNotificationJMS to synchronize instances from >> 2 apps? >> >> They both share the same database and I need updates/changes made >> in the admin app to be visible in searched EOs (possibly already in >> the cache) on the public view >> >> Gino >> >> >> _______________________________________________ >> 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/krank% >> 40logicunited.com >> >> This email sent to [EMAIL PROTECTED] > > _______________________________________________ > 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/drosenberg%40inquira.com > > This email sent to [EMAIL PROTECTED] _______________________________________________ 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]
