Re: How to handle version count overflow
Martin Gregorie wrote:
On Tue, 09 Jun 2009 07:52:25 -0700, oliver789 wrote:
Another idea I got just now is to lock the entire table for select/
insert/update when the version counter needs to be reset. Costly, but
justifiable as the version counter only after a long time runs into
overflow. But an update to reset the version counter still needs to be
done. So locking the table for update doesn't work. You can lock it for
select, but some operation may have started just before you did that.
Another race condition here. Oh no ...
Maybe I just make the version count field 19 digits in width (aka Java
Long), shoot myself into the food and go home ... Some poor developer in
100 years time will have to analyze the problem then and figure out that
the version count needs to be reset ;-).
If the time it will take to overflow the version count field is extremely
long compared with the updating program's run time there's no problem.
You could probably use an int if the program is only accessed from a few
adjacent time zones and is taken down every day or week for housekeeping
and/or backups. Just reset the version count table during program
initialisation before the threads are started. This could be fast, since
it can be a single, table-wide UPDATE operation.
For a 24/7, globally accessed system it may be possible to maintain a set
of version count table rows and an associated thread dispatcher for each
time zone. That would allow threads associated with the zone to be
quiesced and the counts reset during a quiet time for that time zone. The
pause would only last long enough for current threads to end and the
UPDATE to complete, so the impact on throughput should be minimal.
Of course, if the program is intended to run for several years with very
high data volumes being processed you may have to do something rather
more complex...
Can't he just let the version counter wrap around, from 99...99
back to 00...00 again? Yes, this means that any given version value
will eventually be reused. But if the time between wraparounds is
long compared to the "think time" between fetching the data and trying
to update it, that's fine.
The O.P. says it may take "several months or maybe years" for
his counter to reach its maximum value, so wraparound is tolerable
unless he expects someone to fetch some data, wait "several months
or maybe years," and then attempt an update -- and even then, he's
only in trouble if the slow-moving updater just happens to choose
the fleeting moment when the fast-wrapping number has arrived at
the same exact value it had "several months or maybe years" ago.
... but maybe there's something fundamental that I haven't
grasped, not being intimate with Hibernate.
A final thought on the "use a Java long" approach: There is
no danger, I repeat *no* danger that such a counter will wrap
around in a mere hundred years. A hundred years is about 3E9
seconds ("Pi seconds is a nanocentury" -- Tom Duff), and a long
can go a little higher than 9E18. Therefore, the counter will last
more than a century unless he sustains a rate of more than three
billion updates per second the whole time. If he's fairly
confident that the update rate is "only" a million per second,
his counter will last for more than three hundred thousand years.
--
Eric.Sosman@sun.com