Version number or timestamp for optimistic concurrency?

Would you rather use a version number (that will increment) or a ti开发者_如何学编程mestamp to check for concurrency problems?

Version number is better because no matter what format of time you use, it can still be thrown off if the server's clock is wrong or becomes wrong over time.

I have to admit, I've used a time stamp in many databases because it can serve a dual purpose of concurrency checking as well as readability for when the data was last changed. However, using a version number is really the better way to go.

I'd use a version number, particularly if the resource may ever be updated more than the resolution of your timestamps (e.g. if you're storing timestamps to a resolution of seconds, if you have multiple updates within a single second, your versioning will break).

Lieven,

I know you didn't specify SQL Server, but IF you are talking about SQL Server then the datatype TimeStamp would be the best method to use. Despite its description it doesn't really have anything to do the date and time. It's actually just a binary number which changes every time the row has been modified. Thus, if any amendments are made to the row then you kno the timestamp column will change. This has the advantage over version numbers because you, the programmer, do not have to "maintain" the version number. Actual Date/Time timestamps need to be used more carefully as another poster referred to earlier - time differences etc.

Version number. Or if I'm using timestamp, I'll make sure it is UTC - so there is no confusion with the timezone.

If you are on Windows, I recommend to use a globally unique identifier (GUID) as the version identifier.

A timestamp (even if UTC) can make problems if the clock is set by the user. An incrementing number (if hold in memory) can make problems if the server application is restarted, or if it overflows (if it's only a 16-bit or 32-bit integer).

Version number. DateTime is not unique due some reasons, for example 'Daylight saving time' - there could be two '2 AM' h. (Ambiguous Time).

I guess that its more than enough unsigned 32 bit integer, because practically there is a ZERO probability that while saving 4,294,967,295 transaction could occur.