I was discussing with Steve on the HipChat page yesterday that we should
probably enable these forum options:
Enable queued posts:
Ability to put registered users posts to post approval if their post count
is lower than the specified value below. This setting has no effect on the
permission setting for post/topic approval. Maximum post count for queued
If queued posts is enabled, this is the post count the user need to reach
in order to post without post approval. If the users post count is below
this number, the post is stored in the queue automatically.This way we can
make sure spam won't reach the forum because we have to approve all posts
and active users can get their post approved immediately.
We might want to suggest users to use StackOverflow because it's a very
active community there are we could focus on unanswered questions there
too. Maybe we can change the hibernate.org site to display the SO tag link
before our forum. This way we might redirect some posts to SO instead of
the forum. This can decrease the time to get a response, and many easy
questions would get answered by other SO users too.
while reviewing an improvement by Stale about reducing
synchronization, I'm having the impression that the synchronization
could be completely removed.
But there's a comment warning me against that, so for sake of safety
I'm merging the improvement without risking going too far:
// synchronized to avoid multi-thread access issues; defined as
method synch to avoid
// potential deadlock issues due to nature of code.
I tried to figure what "potential deadlock" it's referring to, but I'm
having the impression the comment might be outdated. So I've reduced
the contention to the only include the code block about which I'm not
By looking into git history, it seems the comment isn't related to any
specific fix but was included already when this class was first
Would someone be able to point out what is the issue this is protecting against?
That should allow us to provide an even better patch, although I'll
apply the safe one for now so to at least have the benefits already
when wrapping of result-sets is disabled.
I created a new Java project for the folder containing Hibernate master
and imported the gradle build file (accepted defaults). When I tried
running a unit test, I get a compile error in
org.hibernate.test.schemaupdate.SchemaUpdateDelimiterTest on the call to
"Files.readAllLines( output.toPath() )"
Error:(60, 54) java: method readAllLines in class java.nio.file.Files
cannot be applied to given types;
reason: actual and formal argument lists differ in length
I'd like to single step through some test failures with
PooledThreadLocalLoOptimizer but this is slowing me down.
I'm using Intellij 15.0.2.
the file ibdata1 created by MariaDB has reached the size of 1G.
This happens because when deleting the tables the size of the db does not
There are some possible solutions I can try, but I need to change the
configuration of the db and probably upgrade it.
Would that be ok?
I've also created a JIRA for this:
while creating the basic scaffolding for the new GridDialect, I
called the new Maven module "hibernate-ogm-infinispan-hotrod". Which
is rather long, but descriptive.
Q1: any better name?
The current one which we have working on Infinispan "embedded mode"
is named "hibernate-ogm-infinispan".
Q2: do we need to rename the existing one? If not, what to we call it
in our documentation to disambiguate?
GitHub now provides an option to:
- prevent pushing with the "force" option to a specific branch
- prevent people to delete a specific branch
Considering our workflow and also to prevent user mistakes, I think we
should enable them on the reference repositories (the ones in
I did enable this for Hibernate Search. If someone has good reason to
want delete a branch or push with "force" it's just two clicks away to
disable it.. at least I feel confident against unintentional mistakes.
I'd like to test this later using the ConnectionAcquitionMode. In theory
this should led to zero overhead for real applications.
P.S. I had to remove your image as the mailing list does not accept
On Thu, Nov 19, 2015 at 1:11 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
> I wrote a test to replicate the aggressive release overhead (
> ) and these are my findings:
> The more statements a transaction has, the more obvious the performance
> This was tested with Spring and Bitronix and so it measures Bitronix
> We'll have to update the docs to advise the clients to consider the
> AFTER_TRANSACTION mode for some stand-alone JTA environments.
> I wonder if today's Java EE application servers still require the
> aggressive release as an workaround to their connection leak detection
> On Wed, Nov 18, 2015 at 5:49 PM, Steve Ebersole <steve(a)hibernate.org>
>> Yes, I think that's a good idea. I also think working
>> on ConnectionAcquisitionMode is the best option. The fact that Hibernate
>> delays getting the Connection is so generally not useful.
>> On Wed, Nov 18, 2015 at 9:42 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>>> Thanks for the explanation. I found a discussion from 2006 where you
>>> explained this behavior:
>>> I am currently testing the AFTER_TRANSACTION release mode with Spring
>>> and Bitronix and I think it can give some performance gain over
>>> I'll keep you posted with the final results.
>>> Do you think we should update the docs to explain that this is rather
>>> required by Java EE containers, and it might be fine with stand-along JTA
>>> transaction managers?
>>> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve(a)hibernate.org>
>>>> It was to work around certain containers (not just EE containers) that
>>>> implement "resource containment" checks. The Hibernate Session defers
>>>> getting a JDBC Connection until it actually needs one, which can lead to
>>>> cases like the following where 2 beans share a Session/EM:
>>>> Bean1: get Session, but don't use it yet in way that needs Connection
>>>> Bean1: call Bean2...
>>>> Bean2: get Session, do some work forcing Session to obtain Connection
>>>> Bean2: return (Session still hold Connection)
>>>> At this point, these containers see this as a "leaked" Connection
>>>> because the handle was not released by the end of the scope in which it was
>>>> obtained. Hence, aggressive releasing. My contention at the time was that
>>>> a ConnectionAcquisitionMode would have been better/cleaner. I still feel
>>>> that way, and hope to still come back and add that; so much so in fact that
>>>> the enum already exists :).
>>>>  org.hibernate.ConnectionAcquisitionMode
>>>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>>>>> Does anyone remember why does Hibernate support aggressive connection
>>>>> I've never found this requirement in either JTA or JDBC spec.
>>>>> Was it something required by the Java EE application server?
>>>>> hibernate-dev mailing list
Hi hibernate-dev friends
I created a java framework by using my spare time since 2008, it's finished and published to github 2 months ago, now the tutorial document is finished too.
The most important documents:
tutorial.html(English) and tutorial_zh_CN.html(Chinese)
(These tutorial documents are also provided as the attachments of this email)
(I) Java part: Let's java support "Smart Data Structure".
(a) ObjectModel4Java: smart data structure with bidirectional association
(b) Unstable collement elements: Let set/map support unstable elements/keys
(c) Bubbled event, not only collection, but also collection view can trigger events
(II) JPA part: An ehancement of JPA/Hibernate
(a) ObjectModel4JPA: Enhance ObjectModel4Java to support JPA entity objects
(b) QueryPath: Removes the hard code style fetches and orders in the data access layer, Uses dynamic descriptors that can be specified and dispatched by all the layers.
(c) DistinctLimitQuery: Let's hibernate can do the real paging query with collection fetches when the database is Oracle.
As Steve Ebersole said, the JPA part is not smooth. Yes, he's right, I've used some byte code hack technologies to change the behavior of hibnerate.
Now, my tutorial document is finished so that everyone can understand this framework in short time, if some guys think it's valuable, is it possible to let Hibernate do a little refactor so that I can enhance it more smoothly? or is it possible to merge the JPA part of my framework and Hibernate together?