Re: [hibernate-dev] Timestamper
by Steve Ebersole
I guess the confusion was that I never read anywhere that your solution
involved retrofitting your Timestamper class. I just read that as you
meant code should move to use this new SlewClock instead of
Timestamper. The hibernate-ehcache integration uses
net.sf.ehcache.util.Timestamper, so if y'all changed that internally to
use your new SlewClock then that usage is fine. The only usage of the
org.hibernate.cache.internal.Timestamper class (whose internals you
contributed) is in the test suite code, aka, no production code. Yes,
we should move it to the hibernate-testing package to make that
completely apparent.
On Fri 27 Apr 2012 09:21:26 AM CDT, Alex Snaps wrote:
> I'm confused... The hibernate-ehcache module was using
> net.sf.ehcache.util.Timestamper (from 2.4.3) that internally uses the
> SlewClock ...
> The hibernate packaged one suffer from the initial issue. Is there
> plans to change this ?
>
> On Fri, Apr 27, 2012 at 10:11 AM, Steve Ebersole<steve(a)hibernate.org> wrote:
>> Well but we still have the issue of the hibernate-ehcache integration using
>> net.sf.ehcache.util.Timestamper. And we cannot use your SlewClock there
>> because it is package-protected.
>>
>>
>>
>> On Fri 27 Apr 2012 09:05:56 AM CDT, Alex Snaps wrote:
>>>
>>> Right! I see these are all in the hibernate-testing code. I misread
>>> that sorry! ... and w/o caching, NoCachingRegionFactory is used.
>>> Well, I guess the fact that it might loop for "longer" would be less
>>> of an issue then. I'd maybe just evaluate moving that class into the
>>> hibernate-testing as well maybe, avoiding someone actually uses for
>>> "production" code.
>>>
>>> On Fri, Apr 27, 2012 at 9:52 AM, Steve Ebersole<steve(a)hibernate.org>
>>> wrote:
>>>>
>>>> No, that is not how we "timestamp every Session".
>>>>
>>>> Ok, its there but...
>>>>
>>>> final class SlewClock {...
>>>>
>>>> package-protected
>>>>
>>>>
>>>>
>>>> On Fri 27 Apr 2012 08:49:07 AM CDT, Alex Snaps wrote:
>>>>>
>>>>>
>>>>> Steve,
>>>>> I do see it in the repo on the 2.4.3 tagline :
>>>>>
>>>>>
>>>>> http://svn.terracotta.org/svn/ehcache/tags/ehcache-core-2.4.3/src/main/ja...
>>>>> Also, correct me if I'm wrong, but I think the Timestamper code is
>>>>> used to timestamp every Session, isn't it ? If so, it does impact more
>>>>> than just hibernate-ehcache...
>>>>> I can wire it in and do a pull request. I just wasn't sure that's what
>>>>> you guys wanted ?
>>>>> Alex
>>>>>
>>>>> On Fri, Apr 27, 2012 at 9:40 AM, Steve Ebersole<steve(a)hibernate.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Well, to be specific I am not seeing it in 2.4.3 version of
>>>>>> ehcache-core
>>>>>> jar
>>>>>> (which is jar where Timestamper was found)...
>>>>>>
>>>>>>
>>>>>> On Fri 27 Apr 2012 08:37:53 AM CDT, Steve Ebersole wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
>>>>>>> not seeing SlewClock in 2.4.3 jar.
>>>>>>>
>>>>>>> What version was SlewClock added in?
>>>>>>>
>>>>>>> On Fri 27 Apr 2012 08:36:33 AM CDT, Steve Ebersole wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
>>>>>>>> not seeing SlewClock in 2.4.3 jar.
>>>>>>>>
>>>>>>>> What version was SlewClock added in?
>>>>>>>>
>>>>>>>> On Thu 26 Apr 2012 12:48:31 PM CDT, Steve Ebersole wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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/SlewC...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> steve(a)hibernate.org
>>>>>>>>> http://hibernate.org
>>>>>>>>> --
>>>>>>>>> steve(a)hibernate.org
>>>>>>>>> http://hibernate.org
>>>>>>>>> --
>>>>>>>>> steve(a)hibernate.org
>>>>>>>>> http://hibernate.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> steve(a)hibernate.org
>>>> http://hibernate.org
>>>
>>>
>>>
>>>
>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>
>
>
--
steve(a)hibernate.org
http://hibernate.org
14 years, 1 month
Re: [hibernate-dev] Timestamper
by Steve Ebersole
Well but we still have the issue of the hibernate-ehcache integration
using net.sf.ehcache.util.Timestamper. And we cannot use your
SlewClock there because it is package-protected.
On Fri 27 Apr 2012 09:05:56 AM CDT, Alex Snaps wrote:
> Right! I see these are all in the hibernate-testing code. I misread
> that sorry! ... and w/o caching, NoCachingRegionFactory is used.
> Well, I guess the fact that it might loop for "longer" would be less
> of an issue then. I'd maybe just evaluate moving that class into the
> hibernate-testing as well maybe, avoiding someone actually uses for
> "production" code.
>
> On Fri, Apr 27, 2012 at 9:52 AM, Steve Ebersole<steve(a)hibernate.org> wrote:
>> No, that is not how we "timestamp every Session".
>>
>> Ok, its there but...
>>
>> final class SlewClock {...
>>
>> package-protected
>>
>>
>>
>> On Fri 27 Apr 2012 08:49:07 AM CDT, Alex Snaps wrote:
>>>
>>> Steve,
>>> I do see it in the repo on the 2.4.3 tagline :
>>>
>>> http://svn.terracotta.org/svn/ehcache/tags/ehcache-core-2.4.3/src/main/ja...
>>> Also, correct me if I'm wrong, but I think the Timestamper code is
>>> used to timestamp every Session, isn't it ? If so, it does impact more
>>> than just hibernate-ehcache...
>>> I can wire it in and do a pull request. I just wasn't sure that's what
>>> you guys wanted ?
>>> Alex
>>>
>>> On Fri, Apr 27, 2012 at 9:40 AM, Steve Ebersole<steve(a)hibernate.org>
>>> wrote:
>>>>
>>>> Well, to be specific I am not seeing it in 2.4.3 version of ehcache-core
>>>> jar
>>>> (which is jar where Timestamper was found)...
>>>>
>>>>
>>>> On Fri 27 Apr 2012 08:37:53 AM CDT, Steve Ebersole wrote:
>>>>>
>>>>>
>>>>>
>>>>> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
>>>>> not seeing SlewClock in 2.4.3 jar.
>>>>>
>>>>> What version was SlewClock added in?
>>>>>
>>>>> On Fri 27 Apr 2012 08:36:33 AM CDT, Steve Ebersole wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
>>>>>> not seeing SlewClock in 2.4.3 jar.
>>>>>>
>>>>>> What version was SlewClock added in?
>>>>>>
>>>>>> On Thu 26 Apr 2012 12:48:31 PM CDT, Steve Ebersole wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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/SlewC...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> steve(a)hibernate.org
>>>>>>> http://hibernate.org
>>>>>>> --
>>>>>>> steve(a)hibernate.org
>>>>>>> http://hibernate.org
>>>>>>> --
>>>>>>> steve(a)hibernate.org
>>>>>>> http://hibernate.org
>>>
>>>
>>>
>>>
>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>
>
>
--
steve(a)hibernate.org
http://hibernate.org
14 years, 1 month
Re: [hibernate-dev] Timestamper
by Steve Ebersole
Alex, the issue you mentioned says it was fixed for 2.4.3, but I am not
seeing SlewClock in 2.4.3 jar.
What version was SlewClock added in?
On Fri 27 Apr 2012 08:36:33 AM CDT, Steve Ebersole wrote:
>
> Alex, the issue you mentioned says it was fixed for 2.4.3, but I am
> not seeing SlewClock in 2.4.3 jar.
>
> What version was SlewClock added in?
>
> On Thu 26 Apr 2012 12:48:31 PM CDT, Steve Ebersole wrote:
>>
>> 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/SlewC...
>>>
>>>
>>>
>>> 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
>>
>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
14 years, 1 month
Timestamper
by Alex Snaps
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/SlewC...
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
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
14 years, 1 month
HSEARCH-1084 build failed
by Nicolas Helleringer
Hi all,
Fetching last master tonight I was not able to build :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project hibernate-search-engine: Compilation failure:
Compilation failure:
[ERROR]
\hibernate-search\hibernate-search-engine\src\main\java\org\hibernate\search\impl\MappingModelMetadataProvider.java:[251,34]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds
T,java.lang.annotation.Annotation
[ERROR]
\hibernate-search\hibernate-search-engine\src\main\java\org\hibernate\search\impl\MappingModelMetadataProvider.java:[257,84]
type parameters of <T>T cannot be determined; no unique maximal instance
exists for type variable T with upper bounds
T,java.lang.annotation.Annotation
After a goo bisect it seems 31b485c1aaabd9b0ff178505067147e5628e3010 is the
first bad commit.
It is HSEARCH-1084 Annotation proxies created by Programmatic Mapping
I m still on windows 7 x64 with 1.6.0_24 jvm
Hope it helps.
Niko
14 years, 1 month
[OGM] MongoDB safe mode
by Emmanuel Bernard
BTW, by default MongoDB drivers do not wait for the operation to be executed on the server to return. So you could insert a data that would fail but not be noticed by the client.
To avoid that, you need to pass the safe=true option.
I think we should offer an option to be safe. Should it be the default?
hibernate.ogm.mongodb.safe
Any take on this one? It should be easy enough. Eventually we will want a more fine grained setting but until then let's put that in place.
14 years, 1 month
[OGM] Mapping associations in MongoDB
by Emmanuel Bernard
## Mapping strategy
I think we have explored three main options while implementing the association mapping in MongoDB
1. Put the assoc info within the entity document we navigate from
2. Put the assoc info in a dedicated document and dedicated collection
3. Put the assoc info in n documents (one doc per row) and a dedicated collection
And slightly orthogonal to this, we have considered to use a prefix for the association collection to make sure it does not clash when mapping @ManyToOne @JoinColumn.
I am reading MongoDB in Action and it seems option 1 is the most natural for MongoDB. At least let's offer the option via a property collected by the datastore / dialect. We can decide to reduce options down the road we we have a better grasp. And that will prevent rewriting the dialect every tie someone changes his mind (like me ;P)
## Optimizing what is store
We definitely store the same data over and over (like the table in association rows. At some point we probably will want to clean that up to do a more "natural" mapping.
(More) thoughts on associations?
Emmanuel
PS: this is nothing new but I'd rather capture this info by mail rather than via IRC discussions to consolidate it.
14 years, 1 month
[OGM] Issue with accepting mongodb in master
by Emmanuel Bernard
I'd like to accept MongoDB's work in OGM's master branch. There is one big elephant in the room.
If I don't have MongoDB running in localhost, I can pass the test and thus I can't do a release. That's especially a problem for me as my MongoDB instance is in a VM and thus not localhost. I can't update the hibernate.properties as the release process takes a fork of the repo and does not rely on what's not committed yet.
Does anyone has a solution?
- we could try and let things be overridden with -D properties
- we could try and simply not run tests if the mongodb instance is not up and running
Any other idea?
Does anyone has an idea how to implement that? Frankly, we can't really accept the work in master until we have a solution for this.
Emmanuel
14 years, 1 month
HHH-7265/HSEARCH-1087 ConcurrentModificationException
by Gail Badner
Scott has verified that the failure he is seeing involves 2 synchronizations. The first is from EntityManagerImpl and the second is HSearch.
The problem is that the EntityManagerImpl (anonymous) Synchronization.afterCompletion() closes the session, which in turn, calls TransactionCoordinatorImpl.close() which calls reset(), which clears the synchronizations from the registry. After that finishes, SynchronizationRegistryImpl.notifySynchronizationsAfterTransactionCompletion() attempts to execute HSearch afterCompletion() synchronization, but the registry has already been cleared, resulting in the ConcurrentModificationException.
I initially thought a possible fix would be to defer calling TransactionCoordinatorImpl.reset() if the afterCompletion() synchronizations are being executed. Doing this would be fairly straightforward.
The problem is that, since the EntityManager afterCompletion() synchronization is executed first, the session would be closed before the HSearch afterCompletion() synchronization is executed. I mentioned this to Sanne and he said that the HSearch afterCompletion() synchronization might need access to the persistence context to, for example, initialize a collection, or to get entity state. Obviously it can't if the session is already closed.
Is there a reason why the EntityManager synchronization is registered before the HSearch synchronization?
Is there a way to always make the "session-closing" synchronization last?
Steve, do you see a better way around this?
Thanks,
Gail
14 years, 1 month