Re: Invalidating objects asynchronously
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