Re: How to handle version count overflow
oliver789@web.de wrote:
Each Java Thread creates it's [sic] own (hibernate) transaction when
accessing the database and closes it when finished. So, this has
Just to be clear, you are discussing how your code specifically uses
Hibernate. It's certainly possible generally for code to use Hibernate in a
thread-unsafe way.
nothing to do with java.util.concurrent.* stuff but is about DBMS
transactions.
I was responding to your comment,
I still like to find a simple thread safe solution for this
problem whether it is of practical importance or not.
Lots of thread issues in Java have nothing to do with java.util.concurrent.*
stuff.
The other half of my response to you was:
Most professional DBMSes handle concurrent access quite well without extra effort.
What I am not seeing is what about your situation defeats the DBMS's
concurrency capabilities. I am slightly suspicious that use of an explicit
"locking table" might contribute to a problem. What about built-in JPA (i.e.,
Hibernate) version attributes?
<http://docs.jboss.org/hibernate/stable/annotations/reference/en/html/entity.html#entity-mapping-entity-version>
As to your rollover question, rollover can only happen infrequently,
presumably with a low enough frequency that no outstanding transaction will be
holding on to a low enough version number from a previous rollover time to be
confusing at the next one. If a version number (v) shows up less than (MAX/n)
when all others have version numbers above (MAX - MAX/n), where n is pretty
far below MAX and (MAX + 1) is rollover-equivalent to zero, it's a safe bet
that for now, that low version number really means the equivalent of (MAX + 1
+ v), compared to all those high-numbered versions. By the time there's a
risk of confusion, no outstanding transaction should be above (MAX - MAX/n)
any more; they'll all be in lower number ranges.
--
Lew