• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Invalidating objects asynchronously
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Invalidating objects asynchronously


  • Subject: Re: Invalidating objects asynchronously
  • From: Mike Schrag <email@hidden>
  • Date: Wed, 3 Sep 2008 18:16:17 -0400

We're having an interesting problem in our apps, and I wanted to see if anyone else has solved it.
Yes, with an asterisk. As Travis said, use Project Wonder and the ERXRemoteSynchronizer with JGroups support ... The JMS change notification framework is known to have problems under load. I have tested the remote synchronizer under VERY heavy load tests (500-1000 insanely clicking updating multiple instances) and verified for accuracy of results (accuracy defined as "final state in all instances matches the database"). If JMS is invalidating objects, it's going to be screwed -- you CANNOT invalidate and expect a valid graph state ... We take a performance hit, but in the case where an EO is faulted into the snapshot cache and then modified in a remote instance, we force a refresh from the DB. There is really almost no other way to end up in a safe state (I tried LOTS of approaches -- I rewrote this entire process in 3 different ways until I found all the crazy cases that work). We also properly update inverse relationships (which every other change notification system that I've seen does incorrectly). I'm not saying you can't end up in a potentially wonky state, because this ultimately is impossible to get 100% right, but I've tested all the other popular ones and I can tell you for a 100% fact that they get it wrong. You WILL get deadlocks and you WILL get incorrect graph state. Wonder's is the only one that has was able to get through my butt-wuppin' load test and survive, and I've been using this in a multiple instance application in production for almost 2 years without any graph state exceptions.

As far as sharding your EO's, I definitely agree ... If your data lends itself to sharding, then this is far more ideal (and dependable ... if you get it right). However, there are some cases where you have globally collaborative data that does not lend itself to sharding, or even if it does, you may want to have a shard on multiple instances, which puts you back where you started. There are also often applications that require users to cross shards, which means you have to have a system for dealing with redirecting the user to another instance mid-flight. All completely possible to do, but none of these solutions are trivial (but then we wouldn't have jobs if they were :) ).

ms

_______________________________________________
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


  • Follow-Ups:
    • Re: Invalidating objects asynchronously
      • From: Dan Grec <email@hidden>
References: 
 >Invalidating objects asynchronously (From: Dan Grec <email@hidden>)

  • Prev by Date: Re: clearing a toMany relationship fault
  • Next by Date: Static Resources? - WAS Re: WebObjects/WOnder CSS and Image path issues
  • Previous by thread: Re: Invalidating objects asynchronously
  • Next by thread: Re: Invalidating objects asynchronously
  • Index(es):
    • Date
    • Thread