November 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3961) SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT

by Guenther Demetz (JIRA)

SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT ------------------------------------------------------------ Key: HHH-3961 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3961 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: 3.3.1 GA , SQLServer2008 Reporter: Guenther Demetz Priority: Trivial The method SQLServerDialect#appendLockHint currently ignores the LockMode.UPGRADE_NOWAIT returning the same string as for LockMode.UPGRADE. public String appendLockHint(LockMode mode, String tableName) { if ( mode.greaterThan( LockMode.READ ) ) { // does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)"; return tableName + " with (updlock, rowlock)"; } else { return tableName; } } As SQLServer supports the nowait option I propose the following improvement: public String appendLockHint(LockMode mode, String tableName) { if ( mode == LockMode.UPGRADE_NOWAIT) { return tableName + " with (updlock, rowlock, nowait)"; } else if ( mode.greaterThan( LockMode.READ ) ) { // does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)"; return tableName + " with (updlock, rowlock)"; } else { return tableName; } } A test gave me a correct behaviour: if the concerning row is already locked, then after Lock request time out period exceeded following exception is thrown: org.hibernate.exception.SQLGrammarException: could not lock: [persistent.jpa.AssociationsClassPeer#1] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:115) at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1361) at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:108) at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:87) at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:611) at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:603) ... Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Lock request time out period exceeded. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:196) at com.microsoft.sqlserver.jdbc.SQLServerResultSet$FetchBuffer.nextRow(SQLServerResultSet.java:4700) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.fetchBufferNext(SQLServerResultSet.java:1683) at com.microsoft.sqlserver.jdbc.SQLServerResultSet.next(SQLServerResultSet.java:956) at com.p6spy.engine.spy.P6ResultSet.next(P6ResultSet.java:156) at com.p6spy.engine.logging.P6LogResultSet.next(P6LogResultSet.java:124) at com.mchange.v2.c3p0.impl.NewProxyResultSet.next(NewProxyResultSet.java:2859) at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:97) ... 24 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6848) The duration of hibernate merge rises quadratically with the amount of entities in a to be merged objectgraph

by Wim Ockerman (JIRA)

The duration of hibernate merge rises quadratically with the amount of entities in a to be merged objectgraph ------------------------------------------------------------------------------------------------------------- Key: HHH-6848 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6848 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 4.0.0.CR6, 3.6.8 Environment: Any Hibernate version, any database platform. Reporter: Wim Ockerman Attachments: HibernateMergeMeasurementBeforeAndAfterSolution.png, Sample_JProfiler_hotspot_research_in_a_merge_of_a_big_object_graph.png Tests with merging large objectgraphs showed quadratic rise of duration of the merge related to the object-graph size. >From a certain number of objects in the graph this becomes substantial. This limits hibernate scalability for larger object-graph usages. Analysis (based on 3.6.8 code branch): The merge algorithm of hibernate is a recursive objectgraph walking algorithm. During it's execution it builds up algorithm state information e.g. of merged entities to original objects in the input graph. The information is stored in the EventCache object in the *entityToCopyMap* member. ( org.hibernate.event.def.EventCache) At certain places in the merge algorithm the inverse relation as hold in the EventCache object is needed. see e.g. def.AbstractSaveEventListener.performSaveOrReplicate -> calling persister.getPropertyValuesToInsert(.., *getMergeMap()*,..) The getMergeMap() call calls through to the EventCache's invertMap method. In the implementation of invertMap() a new map is created on the spot and all the elements in the entityToCopyMap where put in, now as copy to entity direction. The call invertMap() happens more in a big detached graph wile merging, and also the size of the entityToCopyMap rises with the number of object already merged in the graph. Thus we have a quadratic relation between the total inverMap() execution time and the number of objects in a graph to be merged. JProfiler screenshot sample attached showing a high call count and high duration time on the invertMap method in a merge vs time it took for a flush of the merged object graph. The latter was unexpected, as the flush time is a good higher bound reference for an object graph operation. To solve this problem see proposed solution in pull request #208 of [hibernate-core] Performance Optimization of in memory merge algorithm. With the solution, the merge duration behaves more linear with respect to the size of the to be merged objectgraph. See attached plot of the original hibernate merge behaviour vs entities in a graph (redline) and the proposed solution's timeing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
15
0 / 0

[Hibernate-JIRA] Created: (HHH-3718) call to id getter initializes proxy when using AccessType( "field" )

by Paul Lorenz (JIRA)

call to id getter initializes proxy when using AccessType( "field" ) -------------------------------------------------------------------- Key: HHH-3718 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3718 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: hibernate 3.3.1, hibernate annotations 3.4.0, running on windows, linux and solaris, using sybase 15 Reporter: Paul Lorenz Calling getter for id when using AccessType( "field" ) causes proxy initialization. In org.hibernate.proxy.proxy.pojo.BasicLazyInitializer there is the code else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } However, when using field access, the getIdentifierMethod will be null. I fixed this for us by changing DirectPropertyAccessor by adding a Method attribute to the DirectGetter inner class, and looking up the appropriate getter in the constructor. As far as I can tell, getMethod is only used in two places. In the above case, to the get the identity getter and in PojoComponentTupilizer.isMethodOf. This doesn't seem to break anything. I don't know if this is a clean solution, seems a little hacky to me, however, it would be great if the issue could be fixed somehow. public static final class DirectGetter implements Getter { private final transient Field field; private final Class clazz; private final String name; private Method method; DirectGetter(Field field, Class clazz, String name) { this.field = field; this.clazz = clazz; this.name = name; try { BeanInfo beanInfo = Introspector.getBeanInfo( clazz ); PropertyDescriptor[] pdArray = beanInfo.getPropertyDescriptors(); if ( pdArray != null ) { for (PropertyDescriptor pd : pdArray ) { if ( pd.getName().equals( name ) ) { this.method = pd.getReadMethod(); } } } } catch ( Exception e ) { // ignore } } public Object get(Object target) throws HibernateException { try { return field.get(target); } catch (Exception e) { throw new PropertyAccessException(e, "could not get a field value by reflection", false, clazz, name); } } public Object getForInsert(Object target, Map mergeMap, SessionImplementor session) { return get( target ); } public Method getMethod() { return method; } public String getMethodName() { return method == null ? null : method.getName(); } public Class getReturnType() { return field.getType(); } Object readResolve() { return new DirectGetter( getField(clazz, name), clazz, name ); } public String toString() { return "DirectGetter(" + clazz.getName() + '.' + name + ')'; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

10
18
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-798) Make use of categories instead of fqcn for logging

by Emmanuel Bernard (JIRA)

Make use of categories instead of fqcn for logging -------------------------------------------------- Key: HSEARCH-798 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-798 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Emmanuel Bernard Fix For: 4.0 http://community.jboss.org/wiki/HowToLogInJBossProjects We need to define the set of categories we wish to have eg: * org.hibernate.search.query * org.hibernate.search.hcore * org.hibernate.search.batchindexing etc The idea behind category is that they are more stable than classes and thus better for the user WDYT? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-295) Generate the "right" FilterKey instance even on parameterized filters

by Emmanuel Bernard (JIRA)

Generate the "right" FilterKey instance even on parameterized filters --------------------------------------------------------------------- Key: HSEARCH-295 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-295 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor Rules around object equality are the most tricky. Not sure we can do a good job at it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-416) Get documentation onto translate.jboss.org

by Hardy Ferentschik (JIRA)

Get documentation onto translate.jboss.org ------------------------------------------- Key: HV-416 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-416 Project: Hibernate Validator Issue Type: Task Components: build, documentation Affects Versions: 4.2.0.Beta1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0.CR1 Need to setup project on translate.jboss.org and integrate with flies maven plugin * http://community.jboss.org/wiki/Flies * http://community.jboss.org/wiki/FliesIntegration -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6801) UUIDBinaryType generates column of type BINARY(255) instead of BINARY(16) in MySQL

by Artem Gelun (JIRA)

UUIDBinaryType generates column of type BINARY(255) instead of BINARY(16) in MySQL ---------------------------------------------------------------------------------- Key: HHH-6801 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6801 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.8 Environment: MySQL 5.1 InnoDB Custom dialect (see HHH-6800) Reporter: Artem Gelun Property definition: {code:xml} <property access="field" name="uuid" not-null="true" type="uuid-binary"> <column name="MI_UUID" not-null="true"/> </property> {code} Debug: {code} 00:13:35,312 DEBUG SchemaExport:415 - create table PCS_MI (MI_CONTAINER bigint not null, MI_ID integer not null, MI_CODE varchar(255), MI_NAME varchar(255), MI_DESCRIPTION varchar(255), MI_TYPE bigint, MI_STATE_CALC_RULE varchar(255), MI_STATE_DICT bigint, MI_EMERG_CALC_RULE varchar(255), MI_ISACTIVE bit default true not null, MI_PARENT_CONTAINER bigint, MI_PARENT_ID integer, MI_UUID binary(255) not null, primary key (MI_CONTAINER, MI_ID)) ENGINE=InnoDB {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5743) Criteria isMember() creates broken SQL in joined queries

by David Momper (JIRA)

Criteria isMember() creates broken SQL in joined queries -------------------------------------------------------- Key: HHH-5743 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5743 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.0, 3.6.1 Environment: Hibernate 3.6.0,3.6.1, all databases Reporter: David Momper Priority: Critical Attachments: Test.zip This problem occurred both when using Oracle, or Derby. I assume it occurs for all databases. I also ran my test case with EclipseLink, and the test passed. A criteria query like this: {quote} CriteriaQuery<Group> groupQuery = cb.createQuery(Group.class); Root<Group> gRoot = groupQuery.from(Group.class); //Get all groups whose leader's name is John, and has a valid visa for given country groupQuery.where(cb.and( cb.like(gRoot.get(Group_.groupLeader) .get(Person_.personName), "%John%"), cb.isMember(country, gRoot.get(Group_.groupLeader) .get(Person_.validVisas) ) )); {quote} produces the following query: {quote} select group0_.GROUP_ID as GROUP1_2_, group0_.LEADER_ID as LEADER3_2_, group0_.GROUP_NAME as GROUP2_2_ from GROUPS group0_, PERSON person1_ where group0_.LEADER_ID=person1_.PERSON_ID and ( person1_.PERSON_NAME like ? ) and ( ? in ( select person1_.PERSON_ID from PERSON person1_ ) ) {quote} The query fails because a (character) country code is being checked for inclusion in a subquery of (int) person ids. The subselect in the above query should be on a country, not a person. I think the whole query should look like this: {quote} select group0_.GROUP_ID as GROUP1_2_, group0_.LEADER_ID as LEADER3_2_, group0_.GROUP_NAME as GROUP2_2_ from GROUPS group0_, PERSON person1_ where group0_.LEADER_ID=person1_.PERSON_ID and ( person1_.PERSON_NAME like ? ) and ( ? in ( select country3_.COUNTRY_CODE from PERSON person1_, PERSON_COUNTRY_VISA validvisas2_, COUNTRY country3_ where group0_.LEADER_ID=person1_.PERSON_ID and person1_.PERSON_ID=validvisas2_.PERSON_ID and validvisas2_.COUNTRY_CODE=country3_.COUNTRY_CODE ) ) {quote} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HHH-5130) Add pointers to Infinispan second level cache

by Sanne Grinovero (JIRA)

Add pointers to Infinispan second level cache --------------------------------------------- Key: HHH-5130 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5130 Project: Hibernate Core Issue Type: Improvement Components: caching (L2), documentation Affects Versions: 3.5.1 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 3.5.x Infinispan is not mentioned in the docs, it should be listed at least in the existing table having all caches. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6405) setFetchMode ignored in certain cases when using criteria queries

by David Mansfield (JIRA)

setFetchMode ignored in certain cases when using criteria queries ----------------------------------------------------------------- Key: HHH-6405 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6405 Project: Hibernate Core Issue Type: Bug Affects Versions: 4.0.0.Beta2, 3.6.5 Reporter: David Mansfield Description: Setting join type (e.g.) criteria.setJoinType("association.path", FetchType.JOIN) is ignored if the association being set is one of a few types. I believe many-to-many, and any association off of a collection-of-component. For these types of associations, the specified fetch type is ignored. This worked in prior versions. This has nothing to do with having additional restrictions on the same association, which is a different issue altogether. Technical analysis: This regression was introduced in git commit fbae6db0abaeb6f050ee97ce53d09d74886a7e47, and the fix for a possibly related issue in git commit 1c556dc775708706b6ca84251cb170d3c46f729f was not a complete fix, or rather did not fix this case scenario. The first referenced commit split the JoinWalker.getJoinType(...) api into two methods, one with more parameters. In the base class implementation, one method or the other is called based on the type of association (see above). However, in the CriteriaJoinWalker (a subclass), the existing implementation only overrode one of these two methods, (the one with more arguments) causing calls into the other method to be handled by the base class, which did not function appropriately. The second referenced commit introduced an override for the second method, however the implementation was incomplete, and was missing the crucial piece, specifically: FetchMode fetchMode = translator.getRootCriteria().getFetchMode( path.getFullPath() ); which examined the explicitly set join types in the translator. A fix will be supplied on github for 3.6.x and 4.0. The implementation re-unifies the two methods in the CriteriaJoinWalker, using if/else to delegate to the correct super.getJoinType(...) method as appropriate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2011