[Hibernate-JIRA] Created: (HHH-2171) Transaction Rollback Problem in GA due to jboss cache alpha dependency
by bhumika thakkar (JIRA)
Transaction Rollback Problem in GA due to jboss cache alpha dependency
----------------------------------------------------------------------
Key: HHH-2171
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2171
Project: Hibernate3
Type: Bug
Components: build
Versions: 3.2.0.ga
Reporter: bhumika thakkar
We upgraded to Hibernate GA, and started getting Transaction Rolloback Exception. GA release is distributed with JBoss cache alpha quality dependency. Upgrading to the current production release of it fixes the issue.
Stack trace:
org.jboss.cache.interceptors.TxInterceptor.runRollbackPhase Rollback had
a problem
java.lang.IllegalStateException: local transaction Transaction[]
transaction does not match running tx null
at
org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback(TxInterc
eptor.java:616)
at
org.jboss.cache.interceptors.TxInterceptor.runRollbackPhase(TxIntercepto
r.java:696)
at
org.jboss.cache.interceptors.TxInterceptor$RemoteSynchronizationHandler.
afterCompletion(TxInterceptor.java:947)
at
org.jboss.cache.interceptors.OrderedSynchronizationHandler.afterCompleti
on(OrderedSynchronizationHandler.java:80)
at
com.caucho.transaction.TransactionImpl.callAfterCompletion(TransactionIm
pl.java:893)
at
com.caucho.transaction.TransactionImpl.commit(TransactionImpl.java:713)
at
com.caucho.transaction.TransactionManagerImpl.commit(TransactionManagerI
mpl.java:263)
at
com.caucho.jca.UserTransactionImpl.commit(UserTransactionImpl.java:411)
at
com.caucho.jca.UserTransactionProxy.commit(UserTransactionProxy.java:142
)
at
org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTr
ansactionManager.java:787)
at
org.springframework.transaction.support.AbstractPlatformTransactionManag
er.processCommit(AbstractPlatformTransactionManager.java:500)
at
org.springframework.transaction.support.AbstractPlatformTransactionManag
er.commit(AbstractPlatformTransactionManager.java:473)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.doC
ommitTransactionAfterReturning(TransactionAspectSupport.java:267)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invok
e(TransactionInterceptor.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
lectiveMethodInvocation.java:170)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo
pProxy.java:176)
at $Proxy119.executeCallback(Unknown Source)
...
--
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
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-3235) Re-assembling entity from clustered JBoss Cache may fail with "argument type mismatch"
by Peter Johnson (JIRA)
Re-assembling entity from clustered JBoss Cache may fail with "argument type mismatch"
--------------------------------------------------------------------------------------
Key: HHH-3235
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3235
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4.sp1
Environment: 3.2.4.sp1 in JBoss 4.2.2 GA, with MySQL 5.0.32 ( JBoss log also reports Hibernate EntityManager 3.2.1.GA, Hibernate Annotations 3.2.1.GA )
Reporter: Peter Johnson
My application is configured for Hibernate to use the JBoss Cache TreeCache and I have the application deployed in a JBoss cluster. For some reason, with the latest deployment of my software (probably coincidentally when I moved to JBoss Seam 2.0) I started running into a problem where I would get an IllegalArgumentException when Hibernate pulled entities out of the replicated instance of the cache.
It looks like when Hibernate pulls values out of the cache and attempts to re-assemble an entity from a CacheEntry, it tries to put a value into the wrong property of the entity. My entity has several int fields and a single String field. The full stack trace is at the end of this description.
Looking briefly at the source for CacheEntry, it appears to store the entity's property values in an array, and when it later obtains the list of properties (from entity metadata) in order to re-assemble the entity, it assumes the order will match the order of the value array in the CacheEntry. So in my case, either the property values must be in a different order in the second JVM's cache instance, or the list of properties in the entity metadata must be different.
Looking at the printDetails of the EJB3EntityTreeCache MBean in both JBoss instances, the CacheEntries seem to have the values in the same order--at least it prints the values in the same order on each instance. This leads me to believe that the entity metadata identifies the properties in a different order in the two JVMs. (I don't have definitive proof, however).
Setting hibernate.cache.use_structured_entries to "true" works around the problem.
2008-04-07 14:52:07,590 ERROR [org.hibernate.property.BasicPropertyAccessor] IllegalArgumentException in class: com.zattoo.channelserver.entity.permission.AbstractPermissionRule, setter method of property: rule
2008-04-07 14:52:07,590 ERROR [org.hibernate.property.BasicPropertyAccessor] expected type: java.lang.String, actual value: java.lang.Integer
2008-04-07 14:52:07,591 INFO [org.hibernate.event.def.DefaultLoadEventListener] Error performing load command
org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of com.zattoo.channelserver.entity.permission.AbstractPermissionRule.rule
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:337)
at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:200)
at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3566)
at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:116)
at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82)
at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:553)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:508)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:357)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:196)
at org.hibernate.collection.PersistentBag.initializeFromCache(PersistentBag.java:141)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:454)
at org.hibernate.engine.StatefulPersistenceContext.initializeNonLazyCollections(StatefulPersistenceContext.java:797)
at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:580)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:508)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:357)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:846)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:557)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:196)
at org.hibernate.collection.PersistentBag.initializeFromCache(PersistentBag.java:141)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.forceInitialization(AbstractPersistentCollection.java:454)
at org.hibernate.Hibernate.initialize(Hibernate.java:309)
at com.zattoo.channelserver.session.ChannelProviderBean.getAllPartitions(ChannelProviderBean.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:101)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
at $Proxy161.getAllPartitions(Unknown Source)
at com.zattoo.channelserver.service.ChannelCacheService.loadPartitionCache(ChannelCacheService.java:136)
at com.zattoo.channelserver.service.ChannelCacheService.getAllPartitions(ChannelCacheService.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:44)
at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:101)
at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:329)
at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:294)
at org.jboss.ejb3.service.ServiceMBeanDelegate.getAttribute(ServiceMBeanDelegate.java:139)
at org.jboss.mx.server.RawDynamicInvoker.getAttribute(RawDynamicInvoker.java:117)
at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:556)
at org.jboss.jmx.adaptor.control.Server.getMBeanAttributeResultInfo(Server.java:144)
at org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:185)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:336)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.inspectMBean(HtmlAdaptorServlet.java:204)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:96)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
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:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:856)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:566)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42)
... 155 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
11 years, 2 months
[Hibernate-JIRA] Created: (EJB-376) EntityManager.createQuery does not recognize COUNT CASE statement
by Mark Plutowski (JIRA)
EntityManager.createQuery does not recognize COUNT CASE statement
-----------------------------------------------------------------
Key: EJB-376
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-376
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.4.0.CR2, 3.3.1.GA
Environment: Tested with both Hibernate 3.2.5.ga and Hibernate 3.3.0.CR2, Postgres 8.1, Postgres 8.2, Linux Ubuntu.
Reporter: Mark Plutowski
I searched the Hibernate forums and did not find mention of this issue or one that was closely related. I also posted this to the Hibernate Users forum, and did not receive any replies recognizing the bug or stating that it has been resolved or has a workaround.
To summarize, EntityManager.createQuery does not recognize SQL related to applying a COUNT to a CASE, whereas it does correctly run SQL that applies a SUM to a CASE. More detail follows.
--- Summary Overview ---
EntityManager.createQuery runs a SELECT query containing the following HQL/JQL snippet runs correctly:
" SUM ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN 1 ELSE 0 END ) "
However, the following do not work:
" COUNT ( DISTINCT CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) "
" COUNT ( DISTINCT (CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) ) "
" COUNT ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) "
The first two statements run and return correct results when translated to SQL and run against the Postgresql database in PgAdmin.
Here's the exception thrown when using COUNT ( DISTINCT CASE WHEN
101976 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: CASE
101977 [main] ERROR org.hibernate.hql.PARSER - line 1:98: unexpected token: WHEN
Here's the exception thrown when the extra parenthesis is added to give COUNT ( DISTINCT (CASE WHEN
85587 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: (
85588 [main] ERROR org.hibernate.hql.PARSER - line 1:99: unexpected token: WHEN
--- Additional Detail ---
Here is the complete SQL for the COUNT (DISTINCT (CASE use case:
String queryString = "Select c.id.pubId, c.id.clipId, c.duration, " +
"count(distinct s.slotId) , " +
" COUNT ( DISTINCT (CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN cs.componentId ELSE NULL END ) ) " +
"from CmClip c " +
"join c.cmClipSlots s " +
"left outer join c.csComponents cs " +
"where (s.adSizeX * c.width) >= :adWidth " +
"and (s.adSizeY * c.height) >= :adHeight " +
"and (c.isQaDone = true or c.isQaDone is null) " +
"and c.isEnabled = true " +
"group by c.id.pubId, c.id.clipId, c.duration " +
"order by " + orderByCol;
This results in the following exception:
85587 [main] ERROR org.hibernate.hql.PARSER - line 1:93: unexpected token: (
85588 [main] ERROR org.hibernate.hql.PARSER - line 1:99: unexpected token: WHEN
Here is the SQL for the SUM CASE sql snippet that does run and return correct results:
String queryString = "Select c.id.pubId, c.id.clipId, c.duration, " +
"count(distinct s.slotId) , " +
" SUM ( CASE WHEN (cs.serveTs BETWEEN :beginTs AND :endTs ) THEN 1 ELSE 0 END ) " +
"from CmClip c " +
"join c.cmClipSlots s " +
"left outer join c.csComponents cs " +
"where (s.adSizeX * c.width) >= :adWidth " +
"and (s.adSizeY * c.height) >= :adHeight " +
"and (c.isQaDone = true or c.isQaDone is null) " +
"and c.isEnabled = true " +
"group by c.id.pubId, c.id.clipId, c.duration " +
"order by " + orderByCol;
Here is the code snippet that performs the transaction:
float roFactor = (float) 0.5;
transactionMgr.begin();
List<Object[]> result = entityMgr.createQuery(queryString)
.setParameter("adWidth", (widthF-roFactor)).
setParameter("adHeight", (heightF-roFactor))
.setParameter("beginTs", beginTs, javax.persistence.TemporalType.TIMESTAMP)
.setParameter("endTs", endTs, javax.persistence.TemporalType.TIMESTAMP)
.getResultList();
transactionMgr.commit();
The fact that "SUM (CASE" is parsed and run correctly, whereas "COUNT (CASE" throws an exception seems to indicate a bug. I replicated this using both (Hibernate 3.2.5.ga with EntityManager 3.3.1.GA) and (Hibernate 3.3.0.CR2 with EntityManager 3.4.0.CR2).
--
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
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-4084) @UniqueConstraint(columnNames="") causes StringIndexOutOfBoundsException
by Ondra Žižka (JIRA)
@UniqueConstraint(columnNames="") causes StringIndexOutOfBoundsException
------------------------------------------------------------------------
Key: HHH-4084
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4084
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.GA
Reporter: Ondra Žižka
Priority: Trivial
Empty string in columnNames attribute causes StringIndexOutOfBoundsException:
@Entity
@Table( name="items", uniqueConstraints=@UniqueConstraint(columnNames="") )
public class Item implements Serializable { ... }
---------------
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.lang.String.charAt(String.java:686)
at org.hibernate.mapping.Column.setName(Column.java:84)
at org.hibernate.mapping.Column.<init>(Column.java:65)
at org.hibernate.cfg.AnnotationConfiguration.buildUniqueKeyFromColumnNames(AnnotationConfiguration.java:591)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:348)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1148)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1226)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:173)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:854)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:425)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:131)
--
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
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-5845) Lazy Loading of audited entites with revision type 'delete'
by Jonas Schlaak (JIRA)
Lazy Loading of audited entites with revision type 'delete'
-----------------------------------------------------------
Key: HHH-5845
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5845
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.6
Environment: Hibernate 3.5.6, Oracle 10 DB
Reporter: Jonas Schlaak
Two classes are given, and they are related via a OneToOne relationship:
@Audited
public class MyClass {
@OneToOne
@Cascade(value = CascadeType.ALL)
private MyOtherClass otherClass;
}
@Audited
public class MyOtherClass {
}
The property "org.hibernate.envers.store_data_at_delete" is set to true, and when auditquerying for the deleted objects and initiliazing the otherClass (an entity which is also deleted) property, and ObjectNotFoundExceptions is thrown. It seems that the proxies do not look for deleted entities, because the same query works fine for the entities of revision type 'ADD' and 'MOD'. The code of the query:
AuditQuery queryDeleted = reader.createQuery().forRevisionsOfEntity(
MyClass.class, false, true).add(
AuditEntity.revisionType().eq(RevisionType.DEL));
List queryResult = queryDeleted.getResultList();
List<MyClass> result = new ArrayList<MyClass>();
for (Object object : queryResult) {
Object[] oArray = (Object[]) object;
MyClass c = (MyClass) oArray[0];
Hibernate.initialize(c.getOtherClass());
}
Forum post with Adam Warski's response:
http://community.jboss.org/thread/160939?tstart=0
--
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
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-2951) Restrictions.eq when passed null, should create a NullRestriction
by David Sheldon (JIRA)
Restrictions.eq when passed null, should create a NullRestriction
-----------------------------------------------------------------
Key: HHH-2951
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2951
Project: Hibernate3
Issue Type: Improvement
Components: query-criteria
Affects Versions: 3.2.1
Reporter: David Sheldon
Priority: Trivial
If you create a Restriction using eq, and pass null to it, then the generated SQL is "where foo = null", which always returns false.
The programmer will almost certainly have intended to get "where foo is null".
Ideally, we could change:
public static SimpleExpression eq(String propertyName, Object value) {
return new SimpleExpression(propertyName, value, "=");
}
to
public static SimpleExpression eq(String propertyName, Object value) {
if (value == null) {
return isNull(propertyName);
}
else {
return new SimpleExpression(propertyName, value, "=");
}
}
Unforunately that wont work, as isNull doesn't return a SimpleExpression.
--
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
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-6615) int type in Revision number
by Adriano Saturno Muniz (JIRA)
int type in Revision number
---------------------------
Key: HHH-6615
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6615
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.6.6
Environment: Hibernata 3.6.6, Oracle
Reporter: Adriano Saturno Muniz
At class DefaultRevisionEntity we have:
@RevisionNumber
private int id;
I made a test setting the HIBERNATE_SEQUENCE to 2,147,483,647. After that, I made an audited update.
The REV column of REVINFO table become negative (int type overflow)
The revision number should be long, at least.
No warnings / exceptions at all could be dangerous. In a overflow all the audit will stop working (envers based the version recoverry in an always increasing REV value, right?). In a very worst scenario, after a long time loosing audit, a primary key violation will happen.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[Hibernate-JIRA] Created: (HHH-3950) org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType
by David Coleman (JIRA)
org.hibernate.MappingException: Type not supported for auditing: org.hibernate.type.IdentifierBagType
-----------------------------------------------------------------------------------------------------
Key: HHH-3950
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3950
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.0.GA
Environment: JBoss Envers: jboss-envers-1.2.0.GA-hibernate-3.3 from org.jboss.envers (not on 3.5 of hibernate core yet)
Hibernate Core: hibernate-core-3.3.0.SP1.jar
JBoss + Seam
Reporter: David Coleman
Attachments: TypeIdentifierBagTypeNotSupportedTrace.txt
Hi,
I currenty have a problem with auditing a many-many relation in the entity show below. Initially I had the exact same problem as ´http://opensource.atlassian.com/projects/hibernate/browse/HHH-3843´' but on reading the documentation and releazing that the list contains duplicate elements, I add (as suggested) a @CollectionId annotation to get bag semantics.
Hoewever, the seam application fails to start-up due to the error being thrown from the envers module: "type not supported for auditing: org.hibernate.type.IdentifierBagType, on entity com.baratz.absys2.core.model.api.User, property 'roles'." (stack trace attached)
<snippet>
@Entity
@Audited
@Table(name = "USER_ABSYS")
public class User {
@UserRoles
@ManyToMany
@JoinTable(name = "USER_ROLE",
joinColumns = @JoinColumn(name = "UUNSEQ",unique=false) ,
inverseJoinColumns = @JoinColumn(name = "ROLE_ID",unique=false))
@TableGenerator(name = "UserRolesGen", table = "ABSYS_SEQUENCE", pkColumnName = "ID_NAME", valueColumnName = "NEXT_VAL", pkColumnValue = "USER_ROLE_ID_GEN", allocationSize=1)
@CollectionId(
columns = @Column(name="USER_ROLE_IDX"),
type=@Type(type="long"),
generator="UserRolesGen"
)
public List<Role> getRoles() {
return roles;
}
...
}
</snippet>
Regards,
Dave
--
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
11 years, 2 months