On 16 mai 2012, at 19:40, Andrej Golovnin wrote:
>
> org.jboss.as.jpa.puparser.PersistenceUnitXmlParser assumes that the
> validation mode would be defined
> in the persistence.xml by the tag "validation-mode". This tag has been added
> in JPA 2.1 which is not yet
> final. Solution: add NONE t
On 05/17/2012 11:53 AM, Andrej Golovnin wrote:
> Hi Steve,
>
>> Deferring initialization of these batch loaders is one option, but that just
>> really delays the memory consumption. Personally, if it were my app I'd
>> rather that sizing be done up front rather than over the course of the next
Sanne, the "problem" discussed here is not the size of the statements
nor the number of rows returned. Its the number of statements
generated and maintained in memory by Hibernate.
Thats being said, I wholeheartedly agree about people trying extremes
as the solution to a problem. An extreme i
On 17 May 2012 17:53, Andrej Golovnin wrote:
> Hi Steve,
>
>> Deferring initialization of these batch loaders is one option, but that just
>> really delays the memory consumption. Personally, if it were my app I'd
>> rather that sizing be done up front rather than over the course of the next
>
On Thu, May 17, 2012 at 6:53 PM, Andrej Golovnin wrote:
> Query: SELECT * FROM test WHERE oid IN (100, 101, 102, 100, 100, 100);
> "Index Scan using test_pkey on public.test (cost=0.00..29.72 rows=*6*
> width=9) (actual time=0.024..0.034 rows=3 loops=1)"
>
> Query: SELECT * FROM test WHERE oid I
Hi Steve,
> And I am certainly fine with allowing this to be a setting between the 3
> approaches:
> 1) Current approach using multiple loaders
-1
> 2) Single loader approach using nulls to "fill out" slots
> 3) Single loader approach re-using keys to "fill out" slots
+1 for any of the above b
Hi Steve,
> Deferring initialization of these batch loaders is one option, but that just
> really delays the memory consumption. Personally, if it were my app I'd
> rather that sizing be done up front rather than over the course of the next
> few hours or weeks as the system continues to run.
On Thu, May 17, 2012 at 5:40 PM, Steve Ebersole wrote:
> Its an index scan, totally trivial (unless their index hashing algos are
> awful as well).
It is.
Unless you have a lot of LEFT JOINs in the query due to your class
hierarchy (that's our case and the resulting queries aren't trivial at
all
And I am certainly fine with allowing this to be a setting between the 3
approaches:
1) Current approach using multiple loaders
2) Single loader approach using nulls to "fill out" slots
3) Single loader approach re-using keys to "fill out" slots
On 05/17/2012 10:42 AM, Steve Ebersole wrote:
> Bes
Besides, how is the plan any different for:
((id = null) OR (id = null) OR (id = null) OR (id = 4) OR (id = 5))
On 05/17/2012 10:40 AM, Steve Ebersole wrote:
> Its an index scan, totally trivial (unless their index hashing algos
> are awful as well).
>
>
> On Thu 17 May 2012 08:49:06 AM CDT, Gu
Its an index scan, totally trivial (unless their index hashing algos
are awful as well).
On Thu 17 May 2012 08:49:06 AM CDT, Guillaume Smet wrote:
> On Thu, May 17, 2012 at 3:02 PM, Steve Ebersole wrote:
>> But just because you have 100 values in no way indicates how many rows will
>> be return
On Thu, May 17, 2012 at 3:02 PM, Steve Ebersole wrote:
> But just because you have 100 values in no way indicates how many rows will
> be returned. And I personally know of no optimizers that make such an
> assumption; its a totally worthless assumption.
That's why I put "simplified" in front of
But just because you have 100 values in no way indicates how many rows
will be returned. And I personally know of no optimizers that make
such an assumption; its a totally worthless assumption.
Nor is this "lack of de-dupping" any real issue that that I can think
of.
On Thu 17 May 2012 07:16:
Hi Steve,
On the list again, my bad...
On Thu, May 17, 2012 at 1:07 PM, Steve Ebersole wrote:
> I am not following what you are saying about "reusing keys" and optimizers.
> Nor how it might lead to bad execution plans. Can you elaborate on your
> thoughts here?
If you have a lot of (OR prima
Hi Eric,
> One option we use on our uPortal installs is to enable
> -XX:+UseCompressedStrings
The support for compressed strings were removed in JDK 7.
Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://
One option we use on our uPortal installs is to enable
-XX:+UseCompressedStrings
It requires a bit more CPU but we are generally memory bound and not CPU
bound. The description reads "Use a byte[] for Strings which can be
represented as pure ASCII. (Introduced in Java 6 Update 21 Performance
R
> Its been proposed a number of times to instead generate just a single
> loader for loading that number of items. This would mean generating a
> single SQL statement that has parameter holders for the full batch size
> and then somehow "filling out" the empty slots when the number of things
actually, thinking about it more, not so sure the "reusing keys"
approach would not work.
On Wed 16 May 2012 04:35:36 PM CDT, Steve Ebersole wrote:
> Well another option is to change the way batch load sql is
> created/handled which is something that has come up many times before,
> and someone w
Well another option is to change the way batch load sql is
created/handled which is something that has come up many times before,
and someone was just discussing on the list last few weeks.
Given a batch size, Hibernate currently generates a non-unintuitive
number of loaders. Lets look at an e
Hi Hardy,
>> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>> without specifying a Locale. Users running Hibernate on systems with
>> Turkish as default
>> locale may see unexpected results. In Turkish there are two lowercase
>> letters
>> \u0069 ‘i’ and \u01
Hi Scott,
>
> Nice find! Could you drill into one of the LockMode loaders and see what the
> larger objects referenced by that are?
>
Largest objects are of type BatchingEntityLoader.
The problem has to do with the value of hibernate.default_batch_fetch_size.
In our case we use 16 as the val
On 05/16/2012 02:32 PM, Andrej Golovnin wrote:
> Hi Scott,
>
>> Validation-mode is part of the JPA 2.0 spec and its not a property.
>>
>> Try adding:
>>
>> NONE
>
> you are absolutely right. I think I was blind. I don't understand
> how could I overlook it.
>
> Thanks!
No worries, its very easy to
Hi Scott,
> Validation-mode is part of the JPA 2.0 spec and its not a property.
>
> Try adding:
>
> NONE
you are absolutely right. I think I was blind. I don't understand
how could I overlook it.
Thanks!
Best regards,
Andrej Golovnin
___
hibernate-d
On 05/16/2012 01:40 PM, Andrej Golovnin wrote:
> Hi Emmanuel,
>
>> javax.persistence.validation.mode NONE
>>
>> should already do that ie disable the integration between JPA and Bean
>> Validation. If that's not the case, there is a bug somewhere but I could not
>> spot it.
>>
>> However, Bea
Hi Emmanuel,
>javax.persistence.validation.mode NONE
>
> should already do that ie disable the integration between JPA and Bean
> Validation. If that's not the case, there is a bug somewhere but I could not
> spot it.
>
> However, Bean Validation has to be activated by the EE container as
On 05/15/2012 05:51 PM, Andrej Golovnin wrote:
> Hi all,
>
> finally I have found the cause of this problem.
>
> But before I describe what caused it, I would like to make two suggestions:
>
> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
> without specifying a Lo
On 16 May 2012 10:47, Hardy Ferentschik wrote:
>
> On May 15, 2012, at 11:51 PM, Andrej Golovnin wrote:
>
>> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>> without specifying a Locale. Users running Hibernate on systems with
>> Turkish as default
>> locale ma
On May 15, 2012, at 11:51 PM, Andrej Golovnin wrote:
> 1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
>without specifying a Locale. Users running Hibernate on systems with
> Turkish as default
>locale may see unexpected results. In Turkish there are two lower
On 15 mai 2012, at 23:51, Andrej Golovnin wrote:
> One more thing: Could we have a property similar to
> "hibernate.listeners.envers.autoRegister"
> for Validator? I would like to disable Validator completely as it produces
> too much garbage
> (look at the pictures) when the application is dep
Hi all,
finally I have found the cause of this problem.
But before I describe what caused it, I would like to make two suggestions:
1. Consider avoiding usage of String#toLowerCase() and String#toUpperCase()
without specifying a Locale. Users running Hibernate on systems with
Turkish as def
Hi Sanne,
> Andrej, what's the overall size you would save by dropping the
> Configuration object?
16187776 bytes.
Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hiber
Hi Steve,
> Take 'temporaryIdTableDDL' as the perfect example. Hibernate cannot know at
> start up (building the SessionFactory) that the application will or will not
> use HQL updates/deletes against "multi-table structures" that would therefore
> need access to 'temporaryIdTableDDL'?
>
> An
On 14 May 2012 13:35, Steve Ebersole wrote:
[cut]
> Configuration is not kept around by Hibernate itself once the
> SessionFactory is built. Nor is SimpleValue. And as Hardy already
> mentioned, that code is undergoing major changes already for 5.0.
Hibernate Search needs to keep a reference to
> - EntityPersisters contain SQL related strings which are never used.
>For example: AbstractEntityPersister#temporaryIdTableDDL and
>#temporaryIdTableName. It exists also in Hibernate 3. I know for sure
>that this #temporaryIdTableDDL is never used in our application
>as the datab
Even using Lists we could trim those instances which are meant for
long-term purpose; not being very familiar with the code in ORM/HEM
I'm not sure which instances they are, but something among these
lines, when inserted in the right places could provide an easy win:
https://github.com/Sanne/hiber
Btw for sure simpleValue should use an arrayList initialized to 1 by default as
it's the most common case.
We might even consider that an array would be better as the final holder even
though there are no agreement in the team yet on the pro/con of arrays vs
collections wrt ease of use, speed a
We deliberately chose to optimize hibernate ORM to be fast even if that means a
bit more memory.
We can try and avoid some objects here as there as you propose but I don't
think that would be as beneficial as finding the real culprit between H3 and
H4's memory consumption difference.
On 12 ma
In java EE 6, applications have access to Bean Validation. That's why you still
see the reference to the serializable validator factory. 256k seems small
enough, let's not waste time on that.
By the way we need to start bean validation to be sure that your entities are
not validated, so the in
Hi Emmanuel,
> Andrej, I wonder if you could share with us these memory dumps privately so
> we could also analyze them.
I'm sorry but this is not possible. But I will give my best to find the root
cause
of this problem.
Here are my findings so far:
- In the memory dump with Hibernate 4 there
Hi Hardy,
> Right, in this case validation mode NONE is the determining factor. I would
> think you get the same result w/ Validator 4.2.0.
Nope, it was the Validator 4.3.0.
> application or as part of the container startup?
> And what exactly do you mean w/ Hibernate Validator gets loaded? D
Hi Scott,
> It sounds like adding value="NONE"/>, is responsible for the memory savings, more than using
> Hibernate Validator 4.3.0. If not, it would be helpful for us to know that.
>
> I wouldn't expect much more savings than that (with validation mode set to
> NONE, we won't pass a validat
On 11 mai 2012, at 00:11, Andrej Golovnin wrote:
> After updating JBoss 7 to use the Hibernate Validator 4.3.0 and
> adding
> to our persistence.xml file I was able to reduce memory consumption
> of SerializableValidatorFactory from ca. 90MB to ca. 256KB. :-)
> What I was not able to do, is to a
On May 11, 2012, at 1:09, Scott Marlow wrote:
>> After updating JBoss 7 to use the Hibernate Validator 4.3.0 and
>> adding
>> to our persistence.xml file I was able to reduce memory consumption
>> of SerializableValidatorFactory from ca. 90MB to ca. 256KB. :-)
>
> It sounds like adding value="
On 05/10/2012 06:11 PM, Andrej Golovnin wrote:
> Hi all,
>
> we use a EAR file which contains a WAR file and a JAR file with
> all our entity classes. And we have a single persistent unit.
> We don't use JavaBean validation, nor we use Hibernate Envers.
>
> Here is a small list with numbers for ou
Hi all,
we use a EAR file which contains a WAR file and a JAR file with
all our entity classes. And we have a single persistent unit.
We don't use JavaBean validation, nor we use Hibernate Envers.
Here is a small list with numbers for our application(not sure
if it would help to understand/solve
On May 10, 2012, at 12:32 PM, Emmanuel Bernard wrote:
> Also how do you come to the conclusion that hibernate ORM + Search take twice
> as much memory? I can't seem to follow your reasoning based on the pics you
> have sent.
> As Sanne point out, Configuration, JavaReflectionManager,
> FullTex
Also how do you come to the conclusion that hibernate ORM + Search take twice
as much memory? I can't seem to follow your reasoning based on the pics you
have sent.
As Sanne point out, Configuration, JavaReflectionManager,
FullTextIndexEventListener exist in both versions. It's unclear to me why
Hi Andrej,
Hibernate Search at version 3.0.1 did a small fraction of what it does
today so I would expect indeed it to take a bit more memory but no I
wasn't aware of significant increases.
Looking just at the Search-related figures however it looks like
memory consumption is significantly *lower
This sounds related to the discussion here
https://community.jboss.org/message/729224#729224.
How many persistence units do you have defined in the application? Can
you get a list of files in the deployment (e.g. run "jar tf
Appname.?ar") and show us the files.
On 05/09/2012 04:58 PM, Andrej
Hi,
it seems that screen shots were stripped by the mailing list software.
I have uploaded them to flickr. Here are the links:
http://www.flickr.com/photos/78207256@N07/7166944408/in/photostream
http://www.flickr.com/photos/78207256@N07/7166945108/in/photostream
Best regards
Andrej Golovnin
On
Hi Shawn,
I experienced some time ago, that turning off the 2nd level could help
getting rid of memory consumption problems, but wasn't able to track down
the problem exactly. Your problem is the same problem as mine. As a solution
I suggested to cut the references to the instances (applicatio
query cache was the lesser of 2 evils for us.
-Original Message-
From: Emmanuel Bernard [mailto:[EMAIL PROTECTED]
Sent: Monday, November 12, 2007 9:42 AM
To: Shawn Clowater
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Memory consumption
No what I am talking about is not relat
:[EMAIL PROTECTED] On Behalf Of Emmanuel
Bernard
Sent: Sunday, November 11, 2007 5:29 PM
To: Markus Heiden
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Memory consumption
You're missing one part, how about custom event listeners. Hibernate
Search used to use those events and n
@lists.jboss.org
Subject: Re: [hibernate-dev] Memory consumption
You're missing one part, how about custom event listeners. Hibernate
Search used to use those events and needed the entity instances for
example.
For the optimization, the JIRA issue has not been created AFAIK.
On Nov 11,
You're missing one part, how about custom event listeners. Hibernate
Search used to use those events and needed the entity instances for
example.
For the optimization, the JIRA issue has not been created AFAIK.
On Nov 11, 2007, at 17:00, Markus Heiden wrote:
Hi Emmanuel,
You need it for
Hi Emmanuel,
You need it for the post commit insert event.
I know, but during the execution of "post commit" code of the
EntityInsertAction only the id of the instance is needed and this should be
retrievable after a flush. So in all cases there is no need to keep the
reference to the insta
You need it for the post commit insert event.
But we could optimize that if there is no such event.
On Nov 9, 2007, at 21:21, Markus Heiden wrote:
After executing actions, the actions (e.g. EntityInsertAction) will
be moved from ActionQueue.inserts etc. to ActionQueue.executions to
stay the
Hi Darryl,
the problem is the memory consumption. The database has no problems with the
size of the transaction (I tested this by increasing the max heap size to 1
GB). The workaround I use works for now, so that I need no complex solution
for first. My intend was to find a real solution for t
Markus Heiden wrote:
After executing actions, the actions (e.g. EntityInsertAction) will be
moved from ActionQueue.inserts etc. to ActionQueue.executions to stay
there until the transaction completes. Because they do have a reference
to the instance being saved, they prevent that instance from
59 matches
Mail list logo
