On Mon, 2011-04-04 at 16:56 -0500, Kevin Grittner wrote:
> SSI allows you to enforce arbitrarily complex user-defined business
> rules within the database without blocking, by automatically
> detecting live race conditions in your SQL transactions at runtime.
> It protects you by safely rolling some of them back (which can be
> retried safely).
"SSI allows you to enforce arbitrarily complex user-defined business
rules within the database without blocking..."
If I heard that statement and nothing else, and then encountered a
problem where SSI was a good solution, I'm not sure I'd make the
connection. It sounds a little vague (most people think SQL already
magically does that), and "complex" is probably a bad word to use
(people often read "complex" as "doesn't apply to me").
Sometimes I try to reverse the order and see if it sounds a little
better. Maybe something like:
"SSI automatically detects any race conditions among concurrent
transactions, and safely rolls some transactions back. That means you
can enforce arbitrary business rules and mix transactions safely without
blocking; and simply retry any failed transactions."
Still a little long, but I like the order a little more. At least for
me, "automatically detects race conditions" seems to have the most
punch, so it makes sense to put it first.
Ordinarily it's good to put a business need first, so I see why you
wrote it that way originally. But in this case, I think that "safety"
and "error detection" can be seen as the business needs; because most
people probably think they are enforcing their business rules already.
If they happen to be doing so safely already, then perhaps you can drill
down into the penalties they are paying in performance (due to blocking)
and/or development time (because getting it right is not easy).
Just my thoughts. It depends on the audience, of course.
Regards,
Jeff Davis
