On Wed, Jan 17, 2007 at 12:27:28PM -0800, Christian Storm wrote:
> Unfortunately, this doesn't exist, so to me pgmemcache has limited
> use unless you believe all your transactions will always succeed and
> you don't care about race conditions.
Or the race condition can be caught and acted on later. One way that
you can solve these sorts of problems is to use cached data (subject
to race conditions &c.) for initial decision, but then your final
state still requires the write in some "real" database. It's
trickier to do things that way, and you don't get nearly the
performance boost you might like, but it is a possible arrangement
for some applications.
The key thing is to do careful analysis of your business
requirements. Sometimes the boost in performance is worth living
with cleanup from race conditions later, if you can do it. This
partly depends on the cost of that cleanup. This sort of analysis is
what's responsible for back-ordered shipments of the "one in stock"
item that you ordered on line, for example. If it was in stock, how
come it's back ordered now? Maybe a race condition, or else a
mistake in the inventory system, or something like that. If the item
is of low enough importance and the back order solved fast enough,
maybe it doesn't matter enough to be work the 100% availability. It
is often hard to convince business types of this analysis, so you
have to do a lot of homework. But making the trade of race condition
for speed is in fact sometimes worth it anyway.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
