I was thinking of having a Metrics gathering API for all sorts of database-related operations:
- connection acquiring/lease time- connection wait time- transaction durations- SQL query logger
- slow queries threshold- number of queries per transaction threshold
Something similar to https://github.com/vladmihalcea/flexy-pool
This will ease profiling a Hibernate application and we could have the hibernate-core define the integration hooks anda hibernate-metrics module to inject the metrics gathering components. This module could use Dropwizard Metrics, sinceit supports various Reservoir types and many reporting flavors (log, JMX, Graphite).
Hibernate users will get an insight of what's going on in their application, so they can better understand what Hibernate doeson their behalf.
What do you think of this?
Hello caching experts!
At last minute before Hibernate ORM 5, I'm proposing a change in the
second level caching SPI.
I've already implemented it, including patching both the Ehcache and
Infinispan modules to satisfy the new requirement, so you don't have
to do much but please have a look and hopefully approve:
The summary is:
- The CacheKey SPI is changed to an interface
- I'm adding a factory method to each Region to allow the cache
implementor to produce its own key implementations
- Patched all current Region implementations to simply produce the
old, proven key implementation.
- Changed all code in ORM which deals with cache access to
exclusively use the new factory.
- All signatures using a "key" have been changed from Object to the
Since Hibernate ORM 5 is almost ready I'm only defining the API
changes; the description on the PR should give some possible
suggestions of optimisations which we could then play with.
As a background: we had several tests showing that the allocation cost
of the CacheKey implementation being "imposed" by the Hibernate core
was quite high; this is a first step to improve that, to allow
slimming of these but also possible further crazy ideas such as
I'm in the process of releasing Hibernate Search 5.3.0.CR1.
This time, we won't wait for the Final release for branching to the
next development iteration: "master" is now version 5.4.0-SNAPSHOT and
you're all welcome to start proposing pull requests meant for 5.4.
Since 5.3.0.CR1 is a candidate release, we don't expect further
changes other than some overdue documentation polishing, to be merged
both in master and branch "5.3".
Of course if regressions are reported we'll re-evaluate the plan,
otherwise I will release 5.3.0.Final the 10th of June.
So for the current work sprint please look at both issues targeting
"5.4" and "5.3.0.Final".
The main goal for 5.4 is to be compatible with Hibernate ORM 5: as
soon as that's integrated we'll publish an Alpha.. hopefully just in a
couple of days.
Does someone have an example of how I could use different Infinispan
Cache(s) for each of my Hibernate entities?
The WildFly documentation doesn't get much into tuning:
I'd like to define Cache configuration in the WildFly configuration
file and map them 1:1 to the cacheable entities.
Which also brings up the question on why I should edit the root
configuration for sake of app-specific details.. ideally I'd want to
add such a configuration snippet within my application deployment.
thanks in advance for any pointer,
HHH-9818 and HHH-9837 contains all the details. Essentially there is
a very bad flaw in how hibernate-osgi is currently propagating class
loading to mapping binding. Fixing this was missed in the 5.0 work. It
only affects AnnotationBinder, but it happens to affect every single
application that uses annotations because it happens to be the code that
loads the entity Class and proxy interface Class references.
Personally I feel that this warrants a CR2. What do y'all think?