Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> Coundn't be predicate locking implementation in SSI be used for
> in-database cache invalidation.
It would not necessarily be limited to *in-database* caches. The
main thing would be to design a good API to the predicate locking
portion of SSI, which I think is about 80% of the SSI code. Dan and
I both have an interest in such further use, and there have been
others who have talked about potential uses for the non-blocking
predicate locking. I think the API would need to be based around a
listen/notify model.
> It could be possible to implement in-database cache which will
> acquire predicate locks like SSI transactions. In case of any
> conflich with other transactions corresponding cache invalidates.
> Therefore, it might be possible to get acceleration of caching
> without risk of inconsistent answers.
I had not thought of that potential use. At first glance, I think
it has possibilities, but only if the above-mentioned API was
formalized *and* there was some way to configure a cluster for
"serializable transactions only". Long-range, I have hopes for
both.
> Actually, I don't understand SSI in details. So, probably I mess
> up things. Does my idea any matter?
Sure! Besides having the available development time, I think the
biggest obstacle is having enough plausible use cases for predicate
lock access to do a good job defining the API. While we made some
effort to keep the predicate locking and serializable behavior
separate in the implementation, it wasn't clear where the "bright
line" was, so there is bound to be some rearrangement needed when we
figure that out. The more ideas we have in front of us on how
predicate locks might be useful, the better the API design is likely
to be.
-Kevin