Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> I thought the big problem with providing true serializability was
> the predicate locking. If it doesn't address that need then does
> this get us any closer?
I thought the big problem was the perception that performance would
suffer and that the level of blocking required would be unacceptable.
This technique (based on available benchmarks from the prototype
implementation) seems to give performance very close to snapshot
isolation with no additional blocking beyond what snapshot isolation
already has to support "first committer wins" update conflict
detection. Benchmarks showed much better performance than traditional
blocking techniques for achieving serializability.
Since it can markedly increase serialization failure rollbacks, the
software needs to be able to respond to those gracefully, but since
our framework automatically re-submits transactions which are
terminated with that SQLSTATE, this approach sound very useful for us.
> Is this like saying walls are a well understood technology so these
> antilock brakes work great for stopping your car as long as you
> combine them with a wall? :)
I see it more like saying that walls are a well understood technology,
and this is a proposal for a way to use them in putting up a
particular useful building.
-Kevin