Pooled Optimiser Improvements
by Stuart Douglas
Hello,
I have been working on a change to the pooled optimizer that we have been seeing good performance results with. Basically it hands out blocks of ID's to a thread local, rather than having every thread contend on the lock every time an ID is required.
https://github.com/hibernate/hibernate-orm/compare/master...stuartwdougla...
What would I need to do to get a change like this in? In particular:
- Does it need to be a new type of optimizer, or is modifying the existing one like I have done OK?
- How should it be configured?
I am happy to do up a PR for this, but I am just not really sure what would be required to get it to a point where it would be acceptable for inclusion.
Stuart
10 years
Forum changes proposal
by Vlad Mihalcea
Hi,
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
posts:
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.
Vlad
10 years
[ORM] Synchronization on AbstractLoadPlanBasedLoader
by Sanne Grinovero
Hi all,
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
confident.
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
created.
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.
thanks,
Sanne
10 years
refresher needed on running Hibernate unit tests in Intellij?
by Scott Marlow
Hi,
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;
required: java.nio.file.Path,java.nio.charset.Charset
found: java.nio.file.Path
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.
Thanks,
Scott
10 years
[CI] MariDB size on jenkins slaves
by Davide D'Alto
Hi,
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
decrease.
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:
https://hibernate.atlassian.net/browse/WEBSITE-418
Cheers,
Davide
10 years
[OGM] The (new) remote Hot-Rod based Infinispan GridDialect
by Sanne Grinovero
Hello all,
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?
Thanks,
Sanne
10 years
GitHub options to disable force pushing
by Sanne Grinovero
Hi all,
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
github.com/hibernate ).
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.
Thanks,
Sanne
10 years
Re: [hibernate-dev] Why does Hibernate has aggressive connection releasing for JTA
by Steve Ebersole
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
attachments.
On Thu, Nov 19, 2015 at 1:11 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> I wrote a test to replicate the aggressive release overhead (
> https://github.com/vladmihalcea/high-performance-java-persistence/blob/ma...
> ) and these are my findings:
>
>
>
> The more statements a transaction has, the more obvious the performance
> impact.
> This was tested with Spring and Bitronix and so it measures Bitronix
> overhead.
>
> 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
> algorithms.
>
> Vlad
>
> On Wed, Nov 18, 2015 at 5:49 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> 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>
>> wrote:
>>
>>> Thanks for the explanation. I found a discussion from 2006 where you
>>> explained this behavior:
>>>
>>> http://lists.jboss.org/pipermail/hibernate-dev/2006-December/000903.html
>>>
>>> I am currently testing the AFTER_TRANSACTION release mode with Spring
>>> and Bitronix and I think it can give some performance gain over
>>> AFTER_STATEMENT.
>>> 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?
>>>
>>> Vlad
>>>
>>>
>>>
>>> On Wed, Nov 18, 2015 at 4:05 PM, Steve Ebersole <steve(a)hibernate.org>
>>> wrote:
>>>
>>>> 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[1] :).
>>>>
>>>> [1] org.hibernate.ConnectionAcquisitionMode
>>>>
>>>> On Wed, Nov 18, 2015 at 1:45 AM Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Does anyone remember why does Hibernate support aggressive connection
>>>>> releasing?
>>>>> I've never found this requirement in either JTA or JDBC spec.
>>>>> Was it something required by the Java EE application server?
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>
10 years
