 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        [Hibernate-JIRA] Created: (HHH-7233) setMaxResults or getSingleResult, combined with pessimistic locking, fails on Oracle with ORA-02014
                                
                                
                                
                                    
                                        by Scott Van Wart (JIRA)
                                    
                                
                                
                                        setMaxResults or getSingleResult, combined with pessimistic locking, fails on Oracle with ORA-02014
---------------------------------------------------------------------------------------------------
                 Key: HHH-7233
                 URL: https://hibernate.onjira.com/browse/HHH-7233
             Project: Hibernate ORM
          Issue Type: Bug
          Components: core
    Affects Versions: 4.1.2
         Environment: Hibernate 4.1.2, Oracle 11gR2
            Reporter: Scott Van Wart
I have a DAO method that does the following:
return this.createNamedQuery( "systemTasks(machineId,status,maxExecuteTimestamp)" )
  .setParameter( "machineId", machineId )
  .setParameter( "status", status )
  .setParameter( "maxExecuteTimestamp", maxExecuteTimestamp )
  .setLockMode( LockModeType.PESSIMISTIC_WRITE )
  .setMaxResults( 1 )
  .getSingleResult();
HQL is:
  select st from SystemTask st
  where st.machineId = :machineId and st.status = :status
    and st.executeTimestamp <= :maxExecuteTimestamp
  order by st.executeTimestamp
Hibernate generates the following SQL:
  select * from (
    select [column list]
    from jaseadm.system_task systemtask0_
    where systemtask0_.machine_id=?
      and systemtask0_.task_status_id=?
      and systemtask0_.execute_timestamp<=?
    order by systemtask0_.execute_timestamp )
  where rownum <= ? for update
Which fails with:
  ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
This means that:
  - setLockMode (pessimistic) can't be used with setMaxResults when there's an order specified, because the oracle dialect only accommodates the "for update" clause and doesn't do anything with an "order by" clause.
  - setLockMode (pessimistic) can't be used with getSingleResult when there's an order by specified, because Hibernate indiscriminately calls setMaxResults in org.hibernate.ejb.getSingleResult():
  boolean mucked = false;
  // IMPL NOTE : the mucking with max results here is attempting to help the user from shooting themselves
  //		in the foot in the case where they have a large query by limiting the query results to 2 max
  //    SQLQuery cannot be safely paginated, leaving the user's choice here.
  if ( getSpecifiedMaxResults() != 1 &&
    ! ( SQLQuery.class.isAssignableFrom( query.getClass() ) ) ) {
    mucked = true;
    query.setMaxResults( 2 ); //avoid OOME if the list is huge
  }
  List<X> result = query.list();
  if ( mucked ) {
    query.setMaxResults( getSpecifiedMaxResults() );
  }
Honestly I would prefer the OOM prevention stuff be removed, or configurable through the session factory, as I end up with a lot of natural key queries that look like:
  select * from ( ... ) where rownum <= 1
When I haven't called setMaxResults myself.
Related to HHH-3298 and HHH-1168 (7 years unresolved).  Note that unlike HH-1168, this breaks getSingleResult as well due to the whole "mucked" code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
        
                                
                         
                        
                                
                                12 years, 11 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        [Hibernate-JIRA] Created: (HHH-5971) Bad performance UpdateTimestampsCache ReentrantReadWriteLock
                                
                                
                                
                                    
                                        by Fernando Paris (JIRA)
                                    
                                
                                
                                        Bad performance UpdateTimestampsCache ReentrantReadWriteLock
------------------------------------------------------------
                 Key: HHH-5971
                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5971
             Project: Hibernate Core
          Issue Type: Bug
    Affects Versions: 3.6.1
         Environment: hibernate 3.6.1, jboss as eap 4.3
            Reporter: Fernando Paris
            Priority: Critical
Performance bootleneck created by UpdateTimestampsCache  invalidate, generating full heap. On the threaddump have 346 threads waiting for
"ajp-0.0.0.0-5490-251" daemon prio=10 tid=0x00002aabc683c000 nid=0x7673 waiting on condition [0x000000005b4da000]
   java.lang.Thread.State: WAITING (parking)
                at sun.misc.Unsafe.park(Native Method)
                - parking to wait for  <0x00002aaac1c8c9d0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
                at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
                at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
                at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
                at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
                at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:807)
                at org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:88)
                at org.hibernate.engine.ActionQueue$AfterTransactionCompletionProcessQueue.afterTransactionCompletion(ActionQueue.java:604)
                at org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:209)
                at org.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:602)
                at org.hibernate.jdbc.JDBCContext.afterNontransactionalQuery(JDBCContext.java:292)
                at org.hibernate.impl.SessionImpl.afterOperation(SessionImpl.java:595)
                at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1273)
                at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
                at org.springframework.orm.hibernate3.HibernateTemplate$34.doInHibernate(HibernateTemplate.java:1024)
                at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
                at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374)
                at org.springframework.orm.hibernate3.HibernateTemplate.findByNamedQueryAndNamedParam(HibernateTemplate.java:1015)
                at com.rumbo.hotel.dbaccess.dao.impl.DhotMetadataDAOImpl.getByDescriptionKey(DhotMetadataDAOImpl.java:46)
                at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameter(HotelParameterCacheManager.java:113)
                at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameterValue(HotelParameterCacheManager.java:76)
                at com.rumbo.alojamientos.tools.parameter.HotelParameterCacheManager.getParameterValue(HotelParameterCacheManager.java:87)
                at com.rumbo.alojamientos.tools.logging.LoggingUtilities.isLogWritingActive(LoggingUtilities.java:189)
                at com.rumbo.alojamientos.tools.logging.LoggingUtilities.isLogWritingActive(LoggingUtilities.java:232)
                at com.rumbo.alojamientos.tools.logging.LoggingUtilities.saveLog(LoggingUtilities.java:141)
                at com.rumbo.hoteles.ws.interceptor.LoggingInterceptor.saveLog(LoggingInterceptor.java:168)
                at com.rumbo.hoteles.ws.interceptor.LoggingInterceptor.handleRequest(LoggingInterceptor.java:94)
                at org.springframework.ws.server.MessageDispatcher.dispatch(MessageDispatcher.java:213)
                at org.springframework.ws.server.MessageDispatcher.receive(MessageDispatcher.java:168)
                at org.springframework.ws.transport.support.WebServiceMessageReceiverObjectSupport.handleConnection(WebServiceMessageReceiverObjectSupport.java:88)
                at org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter.handle(WebServiceMessageReceiverHandlerAdapter.java:57)
                at org.springframework.ws.transport.http.MessageDispatcherServlet.doService(MessageDispatcherServlet.java:230)
                at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
                at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
                at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at com.rumbo.mvc.encoding.EncodingFilter.doFilter(EncodingFilter.java:61)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
                at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
                at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
                at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
                at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
                at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:437)
                at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:381)
                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
                at java.lang.Thread.run(Thread.java:619)
-- 
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
        
                                
                         
                        
                                
                                12 years, 11 months
                        
                        
                 
         
 
        
            
        
        
        
            
        
        
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        [Hibernate-JIRA] Created: (HHH-3298) Hibernate does not correcly apply LockMode.UPGRADE when performing a polymorphic select to a leaf-class via a mapped superclass on Oracle
                                
                                
                                
                                    
                                        by Mike Everett (JIRA)
                                    
                                
                                
                                        Hibernate does not correcly apply LockMode.UPGRADE when performing a polymorphic select to a leaf-class via a mapped superclass on Oracle
-----------------------------------------------------------------------------------------------------------------------------------------
                 Key: HHH-3298
                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3298
             Project: Hibernate3
          Issue Type: Bug
          Components: core
    Affects Versions: 3.2.6
         Environment: Hibernate 3.2.6, Oracle 10gR2
            Reporter: Mike Everett
         Attachments: src.zip
Greetings All,  
I'm experiencing an issue with Hibernate generated SQL when I attempt to retrieve a union-subclass entity via a concrete mapped superclass with LockMode.UPGRADE. 
Hibernate will generate SQL with a UNION ALL of the sub-classes and then apply FOR UPDATE to the query which is not allowed with Oracle.
This leads to the following error: 
java.sql.SQLException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
It seems that "etc." part  includes UNION and UNION ALL.
Example with three classes:
Entity (abstract) <--extends--- ConcreteInheritorOne (concrete) <--extends-- ConcreteInheritorTwo (concrete)
assume: 
inheritorTwoId == the id of an item of class ConcreteInheritorTwo
session == a Hibernate Session
// These lookups will cause the error
Entity e = (Entity) session.get(Entity.class, inheritorTwoId, LockMode.UPGRADE);
Entity e = (Entity) session.get(ConcreteInheritorOne.class, inheritorTwoId, LockMode.UPGRADE);
// This will not cause the error
Entity e = (Entity) session.get(ConcreteInheritorTwo.class, inheritorTwoId, LockMode.UPGRADE);
I have attached entity classes and a Test class which illustrate this effect.
I spelunked into the code a bit, but an easy fix did not present itself to my hibernate-code-virgin eyes.
Thanks for making Hibernate great! 
--Mje
####  Workaround  ####
If anyone else is experiencing this problem, I've implemented code similar to the method below as a work-around in an abstraction layer:
	public Object getEntityForUpdate(Class entityClass, String entityId)
	{
		Session s = getSession();
		ClassMetadata meta = s.getSessionFactory().getClassMetadata(entityClass);
		
		Boolean doTwoPhaseLock = false;
		
		if(meta instanceof UnionSubclassEntityPersister)
		{
			if(((UnionSubclassEntityPersister)meta).getEntityMetamodel().getSubclassEntityNames().size() > 1)
				doTwoPhaseLock = true;
		}
		
		if(doTwoPhaseLock)
		{
			Entity e = (Entity)s.get(entityClass, entityId);
			System.out.println("Using Two-Phase Lock on: EntityId[" + entityId + "] EntityClass[" + entityClass.getName() + "]");
			s.lock(e, LockMode.UPGRADE);
			return e;
		}
		else
		{
			System.out.println("Using One-Phase Lock on: EntityId[" + entityId + "] EntityClass[" + entityClass.getName() + "]");
			return s.get(entityClass, entityId, LockMode.UPGRADE);
		}
	}
#### Hibernate Generated SQL Example ####
select 
     entity0_.id as id6_0_, 
     entity0_.versionNumber as versionN2_6_0_, 
     entity0_.clazz_ as clazz_0_ 
from 
( 
     select versionNumber, id, 2 as clazz_ 
     from BASE_ConcreteInheritorTwo 
     
     union all 
               
     select versionNumber, id, 1 as clazz_ 
     from BASE_ConcreteInheritorOne 
) entity0_ where entity0_.id=? 
for update
####  Stack Trace  ####
15:18:14,484 ERROR JDBCExceptionReporter:78 - ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
15:18:14,484  INFO DefaultLoadEventListener:111 - Error performing load command
org.hibernate.exception.SQLGrammarException: could not load an entity: [org.example.domain.hibernate.Entity#1211505494256]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
	at org.hibernate.loader.Loader.loadEntity(Loader.java:1874)
	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
	at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
	at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3049)
	at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:399)
	at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
	at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
	at org.hibernate.event.def.DefaultLoadEventListener.lockAndLoad(DefaultLoadEventListener.java:297)
	at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:106)
	at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
	at org.hibernate.impl.SessionImpl.get(SessionImpl.java:869)
	at org.hibernate.impl.SessionImpl.get(SessionImpl.java:864)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301)
	at $Proxy0.get(Unknown Source)
	at org.example.test.Test.doTest2(Test.java:68)
	at org.example.test.Test.main(Test.java:35)
Caused by: java.sql.SQLException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
	at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
	at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
	at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
	at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:810)
	at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039)
	at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:850)
	at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1134)
	at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
	at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3384)
	at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
	at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
	at org.hibernate.loader.Loader.doQuery(Loader.java:674)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
	at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
	... 19 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
        
                                
                         
                        
                                
                                12 years, 11 months
                        
                        
                 
         
 
        
            
        
        
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        [Hibernate-JIRA] Created: (HHH-5836) Mapping collection of entities with same name and notnull constraints from two different entities results in duplicate property mapping of Backref
                                
                                
                                
                                    
                                        by Milan Brich (JIRA)
                                    
                                
                                
                                        Mapping collection of entities with same name and notnull constraints from two different entities results in duplicate property mapping of Backref
--------------------------------------------------------------------------------------------------------------------------------------------------
                 Key: HHH-5836
                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5836
             Project: Hibernate Core
          Issue Type: Bug
          Components: annotations
    Affects Versions: 3.5.6
            Reporter: Milan Brich
         Attachments: hibernate-backref-bug.zip
When two entities have OneToMany relationship to third entity and the collection name is same in both entities and nullable is set to false. Then exception written below is thrown.
Caused by: org.hibernate.MappingException: Duplicate property mapping of _parentsBackref found in cz.csas.persistence.test.Parent
	at org.hibernate.mapping.PersistentClass.checkPropertyDuplication(PersistentClass.java:483)
	at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:473)
	at org.hibernate.mapping.RootClass.validate(RootClass.java:236)
	at org.hibernate.cfg.Configuration.validate(Configuration.java:1193)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1378)
	at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:954)
	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:892)
	... 58 more
Attached annotated entities.
-- 
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
        
                                
                         
                        
                                
                                12 years, 11 months