July 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5346) StandardQueryCache not alive after EntityManagerFactory is re-created

by Franck Michel (JIRA)

StandardQueryCache not alive after EntityManagerFactory is re-created --------------------------------------------------------------------- Key: HHH-5346 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5346 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.3 Environment: Ubuntu 8.04 Java SDK 1.6_07 Tomcat 6.0.20 Hibernate-core: 3.3.2.GA Hibernate-annotations3.4.0.GA Hibernate-entitymanager: 3.4.0.GA EhCache 2.1.1 Specific databse product: Data Federator (SAP) JAX-WS stack: 2.1.7 RT Reporter: Franck Michel Hi all, I'm facing a trouble that no post seems to be treating yet: I use Hibernate through the JPA API + EhCache as a 2nd level cache. In the appli. After a long inactivity period, I happen to get a PersistenceException at the first request to my entity manager. In this case, I create a new EntityManagerFactory, and a new EntityManager. At that moment: - the first request raises an exception about the StandardCacheQuery not being alive. - most curious, the second request works fine. The exception stack is listed at the end. Other information about the context follows. Thx in advance for your help. Regards. Franck. - ehcache.xml config: --------------------- same exception happens with or without the StandardQueryCache region configuration. <ehcache> <diskStore path="java.io.tmpdir"/> <defaultCache maxElementsInMemory="20000" eternal="false" timeToIdleSeconds="600" timeToLiveSeconds="600" overflowToDisk="true" diskPersistent="false" diskExpiryThreadIntervalSeconds="600" memoryStoreEvictionPolicy="LRU"/> <cache name="RefTables" eternal="true" maxElementsInMemory="10000" overflowToDisk="false" /> <cache name="org.hibernate.cache.StandardQueryCache" maxElementsInMemory="20000" eternal="false" timeToIdleSeconds="600" timeToLiveSeconds="600" overflowToDisk="true" diskPersistent="false" diskExpiryThreadIntervalSeconds="600" memoryStoreEvictionPolicy="LRU"/> </ehcache> - persistence.xml: ------------------ <persistence-unit name="DataFederator@localhost" transaction-type="RESOURCE_LOCAL"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <class>fr.anr.techlog.neurolog.server.persistence.neurologdb.AcquisitionEquipment</class> <class>fr.anr.techlog.neurolog.server.persistence.neurologdb.Centre</class> <exclude-unlisted-classes>true</exclude-unlisted-classes> <properties> <property name="hibernate.connection.username" value="neurolog"/> <property name="hibernate.connection.password" value="neurolog"/> ... <property name="hibernate.connection.driver_class" value="LeSelect.ThinDriver.ThinDriver"/> <property name="hibernate.connection.url" value="jdbc:datafederator://localhost:3055/schema"/> <property name="hibernate.dialect" value="fr.anr.techlog.neurolog.server.persistence.DataFederatorSQLDialect"/> <property name="hibernate.show_sql" value="true"/> <property name="hibernate.cache.use_second_level_cache" value="true"/> <property name="hibernate.cache.use_query_cache" value="true"/> <property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/> <property name="net.sf.ehcache.configurationResourceName" value="/conf/ehcache.xml"/> </properties> </persistence-unit> Entities: --------- My entities are described with the annotation: @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, include = "non-lazy") or @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, include = "non-lazy") Exception stack: ---------------- java.lang.IllegalStateException: The org.hibernate.cache.StandardQueryCache Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:2191) at net.sf.ehcache.Cache.get(Cache.java:1354) at net.sf.ehcache.hibernate.regions.EhcacheGeneralDataRegion.get(EhcacheGeneralDataRegion.java:58) at net.sf.ehcache.hibernate.regions.EhcacheQueryResultsRegion.get(EhcacheQueryResultsRegion.java:29) at org.hibernate.cache.StandardQueryCache.get(StandardQueryCache.java:130) at org.hibernate.loader.Loader.getResultFromQueryCache(Loader.java:2188) at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2151) at org.hibernate.loader.Loader.list(Loader.java:2121) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401) at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363) at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1149) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102) at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:88) at fr.anr.techlog.neurolog.common.PersistenceManager.retrieveSingleNamedQuery(PersistenceManager.java:521) at fr.anr.techlog.neurolog.common.PersistenceManager.retrieveSingleNamedQuery(PersistenceManager.java:501) at fr.anr.techlog.neurolog.server.metadata.MetadataPuller.findDatasetExpressionById(MetadataPuller.java:147) at fr.anr.techlog.neurolog.server.data.webservices.filemanagement.FileManagement.delegateMakePublicCopyOfDsExpressionFiles(FileManagement.java:633) 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:597) at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246) at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598) at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557) at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542) at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439) at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129) at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160) at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75) 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 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3940) Remove hasSelfReferentialForeignKeyBug (returning true) override from MySQL dialects

by Steve Ebersole (JIRA)

Remove hasSelfReferentialForeignKeyBug (returning true) override from MySQL dialects ------------------------------------------------------------------------------------ Key: HHH-3940 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3940 Project: Hibernate Core Issue Type: Task Components: core Affects Versions: 3.3.1, 3.2.7 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.x, 3.3.x, 3.5 Previous versions of MySQL had a nasty bug when using self-referential foreign keys with the innodb storage engine. This Dialect#hasSelfReferentialForeignKeyBug was originally added to account for that. Testing against the lastest (5.1) MySQL versions shows this to no longer be present. -- 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

14 years, 5 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3995) Cleanup test data

by Steve Ebersole (JIRA)

Cleanup test data ----------------- Key: HHH-3995 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3995 Project: Hibernate Core Issue Type: Task Components: testsuite Reporter: Steve Ebersole Assignee: Steve Ebersole Priority: Minor Fix For: 3.2.x, 3.3.x, 3.5 Lots of tests are leaving test data hanging around. That works on a particular assumption wrt the execution order of tests or that only a single test method exists. That cuases problems later in many cases. All tests should clean up the test data they create. Currently on trunk I see 246 tests leaving data around. The sys prop hibernate.test.validateDataCleanup can be used to check for this; set it to true. -- 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

14 years, 5 months

2
6
0 / 0

[Hibernate-JIRA] Updated: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496?page=c... ] Gail Badner updated HHH-1496: ----------------------------- This issue is currently scheduled for 3.5.x, but not 3.6. Should this issue be fixed in 3.6 as well (or instead)? If so, please correct the fix version(s). Thanks, Gail > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Juraci Paixao Krohling > Fix For: 3.5.x > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- 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

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2439) delay IDENTITY insertions in the case of FlushMode.MANUAL/NEVER

by Steve Ebersole (JIRA)

delay IDENTITY insertions in the case of FlushMode.MANUAL/NEVER --------------------------------------------------------------- Key: HHH-2439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2439 Project: Hibernate3 Type: Improvement Components: core Reporter: Steve Ebersole Assigned to: Steve Ebersole Fix For: 3.2.3 Much like we do now in 3.2 for out of transaction operations, we should delay performing insertions for post-insert generators with FlushMode.isManualFlushMode -- 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

14 years, 5 months

5
20
0 / 0

[Hibernate-JIRA] Updated: (HHH-1851) relax special handling of 'id' property

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851?page=c... ] Gail Badner updated HHH-1851: ----------------------------- This issue is currently scheduled for 3.5.x, but not 3.6. Should this issue be fixed in 3.6 as well (or instead)? If so, please correct the fix version(s). Thanks, Gail > relax special handling of 'id' property > --------------------------------------- > > Key: HHH-1851 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1851 > Project: Hibernate Core > Issue Type: Improvement > Components: query-hql > Environment: independent, all versions all databases. > Reporter: Gunther Schadow > Assignee: Steve Ebersole > Fix For: 3.5.x > > Attachments: IdClassAndAnotherPropertyNamedId.zip > > > Hibernate has long treated 'id' in a special manner in HQL and Criteria queries. The drawback to this has always been that it effectively means users cannot define non-identifier properties named id and refer to those properties in HQL/Criteria queries. > Thus, I will change this such that: > (1) 'id' can still be used to refer to the identifier property, whatever the property's actual name, as long as the entity does not define a non-identitifer property named id. > (2) if the entity defines a non-identifier property named 'id', using 'id' in HQL or Criteria queries will refer to this non-identifier property; users would need to refer to the identifier property by its actual name. > FYI, the original reason for this feature was to support entity's which did not define an identifier property at all (users were responsible for managing the ids seperately. That feature was never really recommended and has been deprecated since early in the 3.x development. -- 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

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4706) Leverage new o.h.dialect.function.TrimFunctionTemplate and o.h.dialect.function.AnsiTrimFunction classes

by Steve Ebersole (JIRA)

Leverage new o.h.dialect.function.TrimFunctionTemplate and o.h.dialect.function.AnsiTrimFunction classes -------------------------------------------------------------------------------------------------------- Key: HHH-4706 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4706 Project: Hibernate Core Issue Type: Improvement Components: core, query-hql Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5 o.h.dialect.function.TrimFunctionTemplate defines basic support for understanding which trim options were specified. o.h.dialect.function.AnsiTrimFunction defines rendering of a trim function using the ANSI SQL defined syntax. -- 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

14 years, 5 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3946) Test FooBarTest isn't opening transactions and contains an invalid assertion

by Juraci Paixao Krohling (JIRA)

Test FooBarTest isn't opening transactions and contains an invalid assertion ---------------------------------------------------------------------------- Key: HHH-3946 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3946 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Juraci Paixao Krohling Assignee: Juraci Paixao Krohling Fix For: 3.5 Attachments: FooBarTest.java.diff Test FooBarTest have three tests failing: - testDisconnect - testOrderBy - testVeto All of them are issuing commit to transactions which were not started, causing "Transaction not successfully started" error. Also, the test testOrderBy contains an invalid assertion. The code reads: assertEquals( "'b' isn't second element", "b", ( (One) results.get(2) ).getValue() ); But as the method "get" is 0-indexed, the parameter should be 1, instead of 2. The attached patch fixes those issues. -- 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

14 years, 5 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4035) skip org.hibernate.action.BulkOperationCleanupAction on INSERT HQL queries

by Steve Ebersole (JIRA)

skip org.hibernate.action.BulkOperationCleanupAction on INSERT HQL queries -------------------------------------------------------------------------- Key: HHH-4035 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4035 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.3.x, 3.5 For INSERT queries it is really not needed to cleanup caches as we'd have no invalid entity/collection data to cleanup (we'd still nee to invalidate the appropriate update-timestamps regions) as a result of the query. -- 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

14 years, 5 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4885) Use "test" durability mode for derby database in testssuites

by Steve Ebersole (JIRA)

Use "test" durability mode for derby database in testssuites ------------------------------------------------------------ Key: HHH-4885 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4885 Project: Hibernate Core Issue Type: Improvement Components: testsuite Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.0-Next Very similar to Oracle's NOLOG option. {quote} While performance is improved, note that under these conditions, a commit no longer guarantees that the transaction's modification will survive a system crash or JVM termination, the database may not recover successfully upon restart, a near-full disk at runtime may cause unexpected errors, and the database may be in an inconsistent state. {quote} http://publib.boulder.ibm.com/infocenter/cscv/v10r1/index.jsp?topic=/com.... -- 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

14 years, 5 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2010