HHH-8310 : WrappedBlob/WrappedClob classloading problem
by Gail Badner
HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
Which would be more appropriate?
Thanks,
Gail
[1] https://hibernate.atlassian.net/browse/HHH-8310
[2] https://jira.spring.io/browse/SPR-11125
10 years, 5 months
SearchFactory API exposes Class type for entity
by Sanne Grinovero
When I started refactoring the Search code towards free-form I simply
started to remove all references to Class and replace them with
TypeIdentifier, essentially working only on hibernate-search-engine
and closing the ORM integration modules which don't need to be
affected.
The SearchFactory interface however is meant as public API and exposes
Class in its signatures to identify specific entity types (I'll use
"entity" in its conceptual meaning): for example we have
void optimize(Class entityType);
Since not only Hibernate Search / ORM will be using Class &
annotations, I could split out the SearchFactory and its default
"class to index mapping" strategies into a separate module, or I could
just keep it there: public API but ignored in case of different
integrations?
I think I'll leave it there for now, but early comments are welcome.
Sanne
10 years, 5 months
Thread-Safety of NoopOptimizer
by Sanne Grinovero
I'm trying to understand if the NoopOptimizer could drop the
"synchronized" at line 53.
I added the synchronization myself some months ago, when we discovered
that we could remove a level of synchronization which was more coarse
grained, but then when inspecting the safety of the various smaller
parts, when hitting the NoopOptimizer I wasn't too sure - as the
AccessCallback is pluggable - and opted to be safe rather than sorry
as I thought this Optimizer would not be used in a high-performance
use case.
It seems I was wrong an some people actually use this Optimizer in a
scenario needing high scalability, and this one also happens to be the
default Optimizer.
By looking at all AccessCallback implementors in the ORM codebase, it
looks like safe to remove the synchronization, but are there reliable
tests I could use to verify this?
There are some more optimisations that come to mind when looking into
the various Optimizer and Generator implementors, but I don't feel
comfortable into changing these without running some stress tests.
TiA,
Sanne
10 years, 6 months
