Re: [hibernate-dev] Database with UUID support

[Steve Ebersole]

The site is not just about the UUID generator project.  He wrote posts on 
ohter subjects as well.

My point there is more to the maven repo.  How do we reference this? 
 Are we ending up hosting another artifact?  How do we even contact 
him to find out?





-- Sent from my Palm Pre
st...@hibernate.org
http://hibernate.orgOn May 27, 2010 1:28 AM, Emmanuel Bernard 
 wrote: 

To his credit a UUID impl is not a 10 year project plan ;) I would not 
necessarily consider it abandonware rather than done.



On 27 mai 2010, at 03:13, Steve Ebersole wrote:



> and the latest posts on that website are

> from 2007.  





___

hibernate-dev mailing list

hibernate-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Database with UUID support

[Steve Ebersole]

Anyway, the discussion here wrt this UUID project is all about
generating the UUID value in Java.  The first point is to determine
whether there is any benefit to relying on the database to generate
these for us in the cases when they can.

Secondly there is the question of if we are going to do it in Java then
what is the correct approach.  Both libraries mentioned here (UUID and
JUG) use MAC address resolution in building the uuid value.  JUG is
updating to use java.util.UUID, but relies on native code for
mac-address-resoltion; UUID use its own UUID class but does not need
native code for the mac-address-resolution (it uses OS-sniffing and
system calls).  Heck maybe we offer this as a strategy configurable with
the Configuration/SessionFactory.

interface UUIDGenerationStrategy extends Serializable {
public int getGenerationVersion(); // informational
public UUID generateUUID(SessionImplementor session);
}

But first things first...

Do we use database uuid generation if supported?  Is that itself perhaps
just a strategy?


On Thu, 2010-05-27 at 06:12 -0500, Steve Ebersole wrote:
> The site is not just about the UUID generator project.  He wrote posts
> on ohter subjects as well.
> 
> My point there is more to the maven repo.  How do we reference this?
>  Are we ending up hosting another artifact?  How do we even contact
> him to find out?
> 
> 
> 
> 
> 
> -- Sent from my Palm Pre
> 
> st...@hibernate.org
> http://hibernate.org
> __
> On May 27, 2010 1:28 AM, Emmanuel Bernard 
> wrote: 
> 
> To his credit a UUID impl is not a 10 year project plan ;) I would not
> necessarily consider it abandonware rather than done. 
> 
> On 27 mai 2010, at 03:13, Steve Ebersole wrote: 
> 
> > and the latest posts on that website are 
> > from 2007. 
> 
> 
> ___ 
> hibernate-dev mailing list 
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev 


-- 
Steve Ebersole 
http://hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Optimizing reflection optimization

[Кирилл Кленский]

Hi,

My measurements have indicated that there is a performance gain. I have
measured the time spent in setPropertyValues and getPropertyValues.
The optimized version was 4 times faster in these methods giving an
estimated application performance increase of about 3%.
Optimizing getPropertyValue and setPropertyValue could give 1.5% more
according to our rough calculations.

Kirill

26 мая 2010 г. 23:53 пользователь Emmanuel Bernard
написал:

> Hi,
> Have you noticed a perf difference in your application with and without the
> patch?
> I am wondering if modern VMs have catched up with what Javassist does.
>
> On 26 mai 2010, at 18:29, Кирилл Кленский wrote:
>
> > 1. I have noticed that
> > org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...)
> is
> > searching for accessor methods in the optimized entity class only. This
> > means that the methods from the superclasses are not visible during
> > BulkAccessor creation unless overridden by child classes. By enhancing
> the
> > algorithm to search down the inheritance tree we could avoid creation of
> > redundant methods which increase the code verbosity a lot. In our case
> > almost all the entities are inherited from the base classes having the
> > common entity properties defined, so the reflection optimization does not
> > work for any of them until we override the inherited methods in all the
> > child classes. The implementation is trivial, but I have got a ready
> > prototype if anybody is interested.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Optimizing reflection optimization

[Steve Ebersole]

I ran this same exact comparison before and I seem to recall much
different results.  Unfortunately I no longer have that code.  This was
part of
http://opensource.atlassian.com/projects/hibernate/browse/HHH-227

Can you make sure you "prime" or "warm up" the jvm before you start
taking measurements?  

On Thu, 2010-05-27 at 15:39 +0300, Кирилл Кленский wrote:
> Hi,
> 
> My measurements have indicated that there is a performance gain. I have
> measured the time spent in setPropertyValues and getPropertyValues.
> The optimized version was 4 times faster in these methods giving an
> estimated application performance increase of about 3%.
> Optimizing getPropertyValue and setPropertyValue could give 1.5% more
> according to our rough calculations.
> 
> Kirill
> 
> 26 мая 2010 г. 23:53 пользователь Emmanuel Bernard
> написал:
> 
> > Hi,
> > Have you noticed a perf difference in your application with and without the
> > patch?
> > I am wondering if modern VMs have catched up with what Javassist does.
> >
> > On 26 mai 2010, at 18:29, Кирилл Кленский wrote:
> >
> > > 1. I have noticed that
> > > org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...)
> > is
> > > searching for accessor methods in the optimized entity class only. This
> > > means that the methods from the superclasses are not visible during
> > > BulkAccessor creation unless overridden by child classes. By enhancing
> > the
> > > algorithm to search down the inheritance tree we could avoid creation of
> > > redundant methods which increase the code verbosity a lot. In our case
> > > almost all the entities are inherited from the base classes having the
> > > common entity properties defined, so the reflection optimization does not
> > > work for any of them until we override the inherited methods in all the
> > > child classes. The implementation is trivial, but I have got a ready
> > > prototype if anybody is interested.
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Steve Ebersole 
http://hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Optimizing reflection optimization

[Bill Burke]

Carlo deWolfe found that one of the big perf problems with Java 
reflection is that it is constantly doing security checks with the 
security manager and every get/find request makes a copy of the 
method/field objects.  He had a hack for this, but you'll have to 
consult him on what it is.  The JBoss Reflections project might have it.

I think once this hack is intiated, it is an improvement over Javassist. 
If you think about it, Java VM has to build up this information anyways...

Steve Ebersole wrote:
> I ran this same exact comparison before and I seem to recall much
> different results.  Unfortunately I no longer have that code.  This was
> part of
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-227
> 
> Can you make sure you "prime" or "warm up" the jvm before you start
> taking measurements?  
> 
> On Thu, 2010-05-27 at 15:39 +0300, Кирилл Кленский wrote:
>> Hi,
>>
>> My measurements have indicated that there is a performance gain. I have
>> measured the time spent in setPropertyValues and getPropertyValues.
>> The optimized version was 4 times faster in these methods giving an
>> estimated application performance increase of about 3%.
>> Optimizing getPropertyValue and setPropertyValue could give 1.5% more
>> according to our rough calculations.
>>
>> Kirill
>>
>> 26 мая 2010 г. 23:53 пользователь Emmanuel Bernard
>> написал:
>>
>>> Hi,
>>> Have you noticed a perf difference in your application with and without the
>>> patch?
>>> I am wondering if modern VMs have catched up with what Javassist does.
>>>
>>> On 26 mai 2010, at 18:29, Кирилл Кленский wrote:
>>>
 1. I have noticed that
 org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...)
>>> is
 searching for accessor methods in the optimized entity class only. This
 means that the methods from the superclasses are not visible during
 BulkAccessor creation unless overridden by child classes. By enhancing
>>> the
 algorithm to search down the inheritance tree we could avoid creation of
 redundant methods which increase the code verbosity a lot. In our case
 almost all the entities are inherited from the base classes having the
 common entity properties defined, so the reflection optimization does not
 work for any of them until we override the inherited methods in all the
 child classes. The implementation is trivial, but I have got a ready
 prototype if anybody is interested.
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Optimizing reflection optimization

[Steve Ebersole]

Perhaps it short circuits those copies and other overheads if no
security manager is defined (ala as in my IDE).  That would explain how
I can see minimal improvement while Kirill sees a 4x improvement.

Still rather confirm these numbers are accurate.  Kirill?

On Thu, 2010-05-27 at 10:12 -0400, Bill Burke wrote:
> Carlo deWolfe found that one of the big perf problems with Java 
> reflection is that it is constantly doing security checks with the 
> security manager and every get/find request makes a copy of the 
> method/field objects.  He had a hack for this, but you'll have to 
> consult him on what it is.  The JBoss Reflections project might have it.
> 
> I think once this hack is intiated, it is an improvement over Javassist. 
> If you think about it, Java VM has to build up this information anyways...
> 
> Steve Ebersole wrote:
> > I ran this same exact comparison before and I seem to recall much
> > different results.  Unfortunately I no longer have that code.  This was
> > part of
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-227
> > 
> > Can you make sure you "prime" or "warm up" the jvm before you start
> > taking measurements?  
> > 
> > On Thu, 2010-05-27 at 15:39 +0300, Кирилл Кленский wrote:
> >> Hi,
> >>
> >> My measurements have indicated that there is a performance gain. I have
> >> measured the time spent in setPropertyValues and getPropertyValues.
> >> The optimized version was 4 times faster in these methods giving an
> >> estimated application performance increase of about 3%.
> >> Optimizing getPropertyValue and setPropertyValue could give 1.5% more
> >> according to our rough calculations.
> >>
> >> Kirill
> >>
> >> 26 мая 2010 г. 23:53 пользователь Emmanuel Bernard
> >> написал:
> >>
> >>> Hi,
> >>> Have you noticed a perf difference in your application with and without 
> >>> the
> >>> patch?
> >>> I am wondering if modern VMs have catched up with what Javassist does.
> >>>
> >>> On 26 mai 2010, at 18:29, Кирилл Кленский wrote:
> >>>
>  1. I have noticed that
>  org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...)
> >>> is
>  searching for accessor methods in the optimized entity class only. This
>  means that the methods from the superclasses are not visible during
>  BulkAccessor creation unless overridden by child classes. By enhancing
> >>> the
>  algorithm to search down the inheritance tree we could avoid creation of
>  redundant methods which increase the code verbosity a lot. In our case
>  almost all the entities are inherited from the base classes having the
>  common entity properties defined, so the reflection optimization does not
>  work for any of them until we override the inherited methods in all the
>  child classes. The implementation is trivial, but I have got a ready
>  prototype if anybody is interested.
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > 
> 


-- 
Steve Ebersole 
http://hibernate.org

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Database with UUID support

[David Driscoll]

In regards to : postgresql - is it reasonable to require this uuid-ossp
module?
In my experience, I avoided using the uuid-ossp module and just used
java.util.UUID.randomUUID() in my
model class to generate my uuid for me instead having the database generate
the uuid.
Depending on how much access rights you have to your database, you might be
able
to easily install uuid-ossp. On the other hand even if you have rights to
install it,
you may wish to avoid taking any maintenance down time which may be
required.

Regards,

Dave


On Thu, May 27, 2010 at 8:01 AM, wrote:

> Send hibernate-dev mailing list submissions to
>hibernate-dev@lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
>hibernate-dev-requ...@lists.jboss.org
>
> You can reach the person managing the list at
>hibernate-dev-ow...@lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
>
> Today's Topics:
>
>   1. Optimizing reflection optimization (?? )
>   2. Database with UUID support (Steve Ebersole)
>   3. Re: Optimizing reflection optimization (Emmanuel Bernard)
>   4. Re: Database with UUID support (Cody Lerum)
>   5. Re: Database with UUID support (Steve Ebersole)
>   6. Re: Database with UUID support (Emmanuel Bernard)
>   7. Re: Database with UUID support (Steve Ebersole)
>   8. Re: Database with UUID support (Steve Ebersole)
>
>
> --
>
> Message: 1
> Date: Wed, 26 May 2010 19:29:01 +0300
> From: ??  
> Subject: [hibernate-dev] Optimizing reflection optimization
> To: hibernate-dev@lists.jboss.org
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> Recently my task involved enabling hibernate reflection optimization in our
> application.
>
> Versions used:
> hibernate-core-3.3.1.GA
> javassist-3.4.GA
>
> Below are some thoughts that hopefully could help to improve the product.
>
> 1. I have noticed that
> org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...) is
> searching for accessor methods in the optimized entity class only. This
> means that the methods from the superclasses are not visible during
> BulkAccessor creation unless overridden by child classes. By enhancing the
> algorithm to search down the inheritance tree we could avoid creation of
> redundant methods which increase the code verbosity a lot. In our case
> almost all the entities are inherited from the base classes having the
> common entity properties defined, so the reflection optimization does not
> work for any of them until we override the inherited methods in all the
> child classes. The implementation is trivial, but I have got a ready
> prototype if anybody is interested.
>
> 2. It seems that it should be also possible to optimize the
> EntityTuplizer's
> getPropertyValue and setPropertyValue calls in the similar way how the
> getPropertyValues and setPropertyValues are currently optimized.
>
> Best regards,
> Kirill Klenski
>
>
> --
>
> Message: 2
> Date: Wed, 26 May 2010 15:24:46 -0500
> From: Steve Ebersole 
> Subject: [hibernate-dev] Database with UUID support
> To: "hibernate-dev@lists.jboss.org" 
> Message-ID: <1274905486.21430.72.ca...@apollo>
> Content-Type: text/plain; charset="UTF-8"
>
> In regards to
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3579 I am
> trying to put together the best all around support for java.util.UUID we
> can as a type.
>
> Obviously most databases "support uuid" via char/varchar data type.
> Postgresql being the lone exception of which I am aware with their
> special UUID datatype, even though they choose to map it to
> java.sql.Types.OTHER (don't get me started).  So for sure we can support
> UUID in every database.
>
> The next logical thought was supporting UUID as an identifier value.  If
> we were to add that what I would really prefer is a way to obtain the
> UUID ahead of time (pre-insert) which would mean knowing what databases
> supported a UUID-generation function and, for those that did, what that
> function is.  For those that do not, is using
> java.util.UUID.randomUUID() a viable alternative?
>
> A list of major databases and their support/non-support for generating
> UUID values that I know of are as follows:
>
> 1) postgresql - database itself does not support generation, instead
> relying on an optional module called uuid-ossp
> 2) mysql - supports generation via the UUID() function
> 3) h2 - supports generation via the RANDOM_UUID()
> 4) hsqldb - does not support generation afaict
> 5) derby - does not support generation afaict
> 6) db2 - does have a GENERATE_UNIQUE() function; was not able to tell if
> that is compatible with java.util.UUID
> 7) firebird - supports gen