I am not sure what the ERJGroupsSync code buys me over JMS (I will take a look though).
It buys you a more-correct vs a known-to-be-not-correct implementation :) 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?
You can NOT ... DOUBLE NOT ... touch the object store coordinator without locking. Terrible things will happen ... Sometimes that will be lockups, sometimes that will be corrupted caches, and sometimes you won't find that out until you have a lot of users at once, but terrible things WILL happen.
However, the JMS notification is known to create lockups, and nobody has worked on that code for years, so the problems aren't going away with it. Also, I would wager you are, in fact, not getting all your notifications, too, because it's REALLY hard to get the notifications you need without hooking into EOF in wacky ways -- ways that I know JMS is not. For instance, updating the inverse to-many relationships does not always result in a notification in the normal way that most of these change notifiers expect ... The only way you can guarantee that you get these notification is by hooking into the actual cache in EOF so that if the cache updates, you know, and that's what ERJG does. The problem is that when it fails, it fails in really subtle ways that are really hard to track down. EOF is MOSTLY right, but just a couple things aren't quite up-to-date. ERJG has been run through lots of 1000 concurrent-users-going-spastic-changing-things testcases with a full EOF cache comparison process at the end to guarantee 100% match, and it passes. This is again not to say it doesn't have bugs, but rather that it has been put through lots of testing.
ms
|