Thanks for the heads up Alex. https://hibernate.onjira.com/browse/HHH-7282
On Thu 26 Apr 2012 11:11:36 AM CDT, Alex Snaps wrote: > Hey, > I wanted to draw your attention to "an issue" we've hit with the > nonblocking implementation of Timestamper, that you guys use as well. > Basically, if time goes backwards, calling next() would loop until > time is passed the last seen value (see > http://jira.terracotta.org/jira/browse/EHC-853) > Technically, time shouldn't go back. Especially the DST issue is none > in my opinion. But NTP daemons that do set clock back might be more > common. > As every session is timestamped, if I read > SessionFactoryImpl.SessionBuilderImpl.openSession correctly, this > would be larger issue to you guys now as well. There are obviously > more people using Hibernate w/o Ehcache than with it. > Anyways, as a solution to that, Chris and I came up with a > non-blocking SlewClock implementation that would simply, in case > System.currentTimeMillis() returns a value "in the past, slow time > down until the wall clock has caught up: > http://www.massapi.com/source/ehcache-2.4.3/src/net/sf/ehcache/util/SlewClock.java.html > Since Timestamper is again core to 2nd level cache usage in Hibernate, > it would make sense to this out of our code base and have it in yours > (as well, as we'd still use it in for the 3.x). > Should I go ahead and create a jira, pull request, ... ? Cause, based > on my experience, blaming it on crappy env. hasn't really worked out > for me ;-) > Alex -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
