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
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
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:
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 ;-)