EHC ❯ AbstractRegionFactory uses Hibernate's Timestamper...
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
alexsnaps
-
Reporter: alexsnaps
-
September 13, 2010
-
0
-
Watchers: 3
-
July 27, 2012
-
January 19, 2011
Description
… which, while correct, synchronizes on the Class’ instance monitor and that’s slow. Same algorithm should be re-implemented using CAS’ing
Comments
Alexander Snaps 2010-09-13
Steve Harris 2010-09-21
Yeah, lets fix and donate back to hibernate (also try to get committer). Is their something we can do easily for this release or should we wait till freo?
MAd Max 2011-04-20
After switch to new Timestamper, i have many line of log with info Thread spin-waits on time to pass. Looped 1459250 times, you might want to increase -Dnet.sf.ehcache.util.Timestamper.shift How i can to switch to old Timestamper from hibernate?
Alexander Snaps 2011-04-20
You can’t. While you might not have seen this before, it is worthwhile understanding what differences there are. First, is you application slower now than it was before ? I’d expect not, but I could be wrong. Also, if you did encounter that condition before, while not logging anything, Hibernate’s Timestamper was giving out a duplicated timestamp, which can result in potential data corruption issues As mentioned in the log, you can increase the value of the net.sf.ehcache.util.Timestamper.shift system property (default is 12) to provide more counter space for sessions per seconds.
Archie Cobbs 2011-04-28
We also are seeing this: {noformat} Thread spin-waits on time to pass. Looped 1563731743 times, you might want to increase -Dnet.sf.ehcache.util.Timestamper.shift {noformat}
Note: that’s over a billion times around the loop!
I don’t care what you say, *if this code can ever possibly loop a billion times, it’s by definition broken.*
This code is a good example of the maxim: “Premature optimization is the root of all evil”.
Replace this bogus “optimization” code with a simple {{synchronized}} statement for goodness sake!
is that something we’d want to donate back again ? JBossCache bypasses that using System.currentTimeMillis(), which is actually not semantically correct. Donating back to Hibernate would enable them to use it as well so that they’d keep the speed advantage, but gain the correctness they currently lack. Now given the low communication between JBoss teams, JBC might actually never know.