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 16 May 2012 16:15, Scott Marlow wrote:
> On 05/16/2012 11:00 AM, Scott Marlow wrote:
>> On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>>>
>>> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>>>
According to JPA 2.0 specification section 3.2.7.1, when merging a
detached entity with laz
On 05/16/2012 11:00 AM, Scott Marlow wrote:
> On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>>
>> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>>
>>> According to JPA 2.0 specification section 3.2.7.1, when merging a
>>> detached entity with lazy associations that haven't been fetched:
>>>
>>> "
On 05/16/2012 10:16 AM, Emmanuel Bernard wrote:
>
> On 16 mai 2012, at 14:28, Scott Marlow wrote:
>
>> According to JPA 2.0 specification section 3.2.7.1, when merging a
>> detached entity with lazy associations that haven't been fetched:
>>
>> "
>> The persistence provider must not merge fields ma
On 16 mai 2012, at 14:28, Scott Marlow wrote:
> According to JPA 2.0 specification section 3.2.7.1, when merging a
> detached entity with lazy associations that haven't been fetched:
>
> "
> The persistence provider must not merge fields marked LAZY that have not
> been fetched: it must ignore
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
According to JPA 2.0 specification section 3.2.7.1, when merging a
detached entity with lazy associations that haven't been fetched:
"
The persistence provider must not merge fields marked LAZY that have not
been fetched: it must ignore such fields when merging.
"
After merging an entity, will
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
19 matches
Mail list logo
