Chris,
I thought a lot about this solution the last couple of days. Using a
timeout as a standard expected event in handling a concurrency issue is
not the best approach, I'm sure Jim would agree.
But there are extenuating circumstances. You have shown that we need to
protect other threads that call hasData() from calling that concurrently
with an active chill thread because it could be there in one instant and
not the next. The act of chilling a record is very intrusive and
dangerous without a record mutex. But using a record mutex is against
Jim's MVCC philosophy for many reasons which need not be listed here. We
just can't do it. So testing and using the syncPrior as an alternative
to the record mutex is OK, I think. Especially since there is no hard
requirement to chill any particular record.
Since the action on the record is not required, and chilling should not
happen very often, I think a timeout and move-on approach is acceptable
here.
Especially since I cannot think of a better approach! :)
Jim, this is your invitation to spark a better idea, or think of a
better approach. Note that this use of syncPrior during a chill
actually works, even though it is not pretty.
Kevin
Christopher Powers wrote:
> ...call me today 612-729-1519 or my cell, 612-616-1069. I'd like to
> discuss the changes I did for garbage collect.
>
> I pushed the fixes to mysql-6.0-falcon-chris on PB2, and *both*
> falcon_online_alter and falcon_chill_thaw passed. I find this to be very
> encouraging.
>
> Using syncPrior in chill was not straightforward solution because of a
> deadlock with a low-level thaw, but what I have works.
>
Attachment: [message/rfc822] Attached Message
Attachment: [message/rfc822] Attached Message
