|
|
Posted by dhek on 11/04/07 19:55
> Just to make things clear: is this the timestamp data type, or a datetime
> value? (It sounds like the latter, but I want to be sure.)
this is a datetime value obtained by the function GETUTCTIME()
> From this description, it sounds that SERIALIZABLE would do the job, but
> I think there is a better solution. Do this:
>
> SELECT @mynewtimestamp = getdate()
>
> SELECT ... FROM tbl
> WHERE regdate BETWEEN @myoldtimestamp AND @mytimestaamp
>
> By first determining the upper limit of the span you will read,
> there is no problem with rows that are added later, because they will
> be outside your range.
I most definitely agree with u - its so simple and so right. I does however
still leave a small time window for the problem to still exist, but I guess
we're now dealing with a more theoretical issue than one that is likely to
actually occur.
In any case - this model should be used:-)
> I would strongly recommend against using serializable, because if
> conflicting updates really is a seroius possibility, using serializable
> is likely to wreak havoc with the concurrency of the system. Your
> replication may work, but if people can place orders while your
> replication is running, that can be a serious problem.
I agree - this is also my fear and is exactly why I didn't really felt too
happy about this solution. But I do believe it would also solve my issue,
since it would disallow for new data to be added that conflict with the
dataset at hand (my where-clause in the SELECT-statement part).
> An interesting observation is that as I understand you scenario is
> that snapshot isolation would *not* work, despite what I said before.
> With snapshot you would miss rows that had been inserted when you started
> reading, but which had not been committed.
>
> This shows just how important it is to give a completely picture of the
> problem you are trying to solve.
hehe, point taken:-)
Navigation:
[Reply to this message]
|