You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Mike D. (JIRA) <no...@at...> - 2006-06-01 20:20:23
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-653?page=comments#action_23238 ] Mike Desjardins commented on HBX-653: ------------------------------------- Same here... JDK 1.4.2. > codegen only runs on jdk 1.5 > ---------------------------- > > Key: HBX-653 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-653 > Project: Hibernate Tools > Type: Bug > Components: eclipse > Reporter: Max Rydahl Andersen > Fix For: 3.1beta5a > > > usage of parseBoolean prohibts <1.5 usage. > Message: Problems occurred when invoking code from plug-in: "org.eclipse.jface". > java.lang.NoSuchMethodError: java.lang.Boolean.parseBoolean(Ljava/lang/String;)Z > at org.hibernate.eclipse.console.model.impl.ExporterDefinition.createProperties(ExporterDefinition.java:70) > at org.hibernate.eclipse.console.model.impl.ExporterDefinition.<init>(ExporterDefinition.java:50) > at org.hibernate.eclipse.console.ExtensionManager.findExporterDefinitions(ExtensionManager.java:54) > at org.hibernate.eclipse.launch.ExporterSettings.createControl(ExporterSettings.java:80) > at org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationTabGroupViewer.showTabsFor(LaunchConfigurationTabGroupViewer.java:720) -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-01 19:35:27
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23237 ] Emmanuel Bernard commented on HHH-1293: --------------------------------------- so use 3.2 and javassist > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Daniel S. (JIRA) <no...@at...> - 2006-06-01 19:24:27
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23236 ] Daniel Serodio commented on HHH-1293: ------------------------------------- @mike: while I sympathize with you, the change in Hibernate code did not _cause_ the problem, it only triggered a JVM bug. We should be pestering Sun about this, not the Hibernate team. Meanwhile, try using BEA's JRockit VM. > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: mike p. (JIRA) <no...@at...> - 2006-06-01 19:14:35
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23235 ] mike perham commented on HHH-1293: ---------------------------------- My unit tests were forking a VM without the -server flag. Sorry for the false alarm. It is now working for us. @Emmanuel: just because Hibernate is not the root cause does not mean the Hibernate guys should walk away here. This was working in 3.1rc2 and then broke in 3.1 final. Look at the number of comments and votes on this issue - it's causing a lot of users pain and so is a prime candidate for a workaround. I would like to understand why the Hibernate team can't roll back the change which caused the problem in the first place. > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Sergiy K. (JIRA) <no...@at...> - 2006-06-01 18:46:30
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23234 ] Sergiy Kyrylkov commented on HHH-1293: -------------------------------------- Andreas , I haven't heard back from Sun since I submitted the bug. > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Andreas S. (JIRA) <no...@at...> - 2006-06-01 17:59:41
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23232 ] Andreas Schildbach commented on HHH-1293: ----------------------------------------- @ sergiy: Is there any news regarding the bug report at SUN. I know it has already been asked, but could you post a link? > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: mike p. (JIRA) <no...@at...> - 2006-06-01 16:29:04
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293?page=comments#action_23230 ] mike perham commented on HHH-1293: ---------------------------------- We are using Hibernate 3.1.3 on Linux 2.6.13-1.1532_FC4 with java: java version "1.4.2_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03) Java HotSpot(TM) Server VM (build 1.4.2_10-b03, mixed mode) And neither -server nor -Xint are working for us since upgrading to 3.1.3. -server with Hibernate 3.1 was working with this setup. Is anyone else running 3.1.3 successfully? Why does this bug have twice as many votes as the next closest bug, is marked as a Blocker and yet has not been fixed in six months? Rollback the original code change already! > java.lang.NoSuchMethodError: <persistent class>.getHibernateLazyInitializer() > ----------------------------------------------------------------------------- > > Key: HHH-1293 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1293 > Project: Hibernate3 > Type: Bug > Versions: 3.1.1 > Reporter: Andreas Schildbach > Priority: Blocker > Attachments: manysessions.tgz > > > As documented in > http://forum.hibernate.org/viewtopic.php?t=940119 > some people (including me) are getting this exception with the final release of Hibernate 3.1: > java.lang.NoSuchMethodError: de.schildbach.game.integration.HibernateGamePlayer.getHibernateLazyInitializer()Lorg/hibernate/proxy/LazyInitializer; > at de.schildbach.game.integration.HibernateGamePlayer$$EnhancerByCGLIB$$afecb986.getHibernateLazyInitializer(<generated>) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:274) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.type.TypeFactory.assemble(TypeFactory.java:398) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:96) > at org.hibernate.cache.entry.CacheEntry.assemble(CacheEntry.java:82) > at org.hibernate.event.def.DefaultLoadEventListener.assembleCacheEntry(DefaultLoadEventListener.java:520) > at org.hibernate.event.def.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:474) > at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:328) > at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123) > at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:202) > at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:169) > at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87) > at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:869) > at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:838) > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266) > at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177) > at org.hibernate.collection.PersistentList.initializeFromCache(PersistentList.java:378) > 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:1627) > at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) > at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) > at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) > at org.hibernate.collection.PersistentList.size(PersistentList.java:91) > The exception varies with the actual persistent class in use. Most people seem to be using JDK 1.5 and Linux. Some reports say that the exception does not happen from the very start of the application, but it takes "several invocations"/"some time" until it appear, but then it appears very often. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 14:26:40
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23229 ] Thomas Boerkel commented on HHH-1808: ------------------------------------- Thanks for all the information. Still it would be very nice to be able to do: flush() clear("events.Person") createQuery("update Person set age = 20").executeUpdate() > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-01 13:51:24
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23228 ] Emmanuel Bernard commented on HHH-1808: --------------------------------------- flush() clear() executeUpdate() is the right thing to do to be safe > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Deyan B. (JIRA) <no...@at...> - 2006-06-01 13:24:22
|
When there are composite keys JBoss Seam Skeleton App [beta] exporter throws an error "Expression field.value.typeName is undefined on line 35, column 6 in seam/find.jsp.ftl" ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HBX-670 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-670 Project: Hibernate Tools Type: Patch Components: hbm2seam Versions: 3.1.beta5 Environment: JBossIDE1.6GA, Eclipse 3.1.2, Hibernate 3.1, Oracle 10i, Linux amd64 Reporter: Deyan Bontchev Priority: Blocker Attachments: editorbean.java.ftl, find.jsp.ftl If there are composite keys in the database schema, the JBoss Seam Skeleton App [beta] exporter throws an error when parse composite identifier property: !ENTRY org.hibernate.eclipse 1 10000 2006-06-01 09:17:37.364 !MESSAGE DEBUG Worker-0 org.hibernate.tool.hbm2x.TemplateHelper - putInContext pojo=org.hibernate.tool.hbm2x.pojo.EntityPOJOClass(persistence.data.UserFlow) !ENTRY org.hibernate.eclipse 1 10000 2006-06-01 09:17:37.377 !MESSAGE DEBUG Worker-0 org.hibernate.tool.hbm2x.TemplateHelper - putInContext clazz=org.hibernate.mapping.RootClass(persistence.data.UserFlow) !ENTRY org.hibernate.eclipse 4 40000 2006-06-01 09:17:37.381 !MESSAGE ERROR Worker-0 freemarker.runtime - !STACK 0 Expression field.value.typeName is undefined on line 35, column 6 in seam/find.jsp.ftl. The problematic instruction: ---------- ==> if-else [on line 35, column 1 in seam/find.jsp.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression field.value.typeName is undefined on line 35, column 6 in seam/find.jsp.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.ComparisonExpression.isTrue(ComparisonExpression.java:121) at freemarker.core.IfBlock.accept(IfBlock.java:80) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:79) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:160) at freemarker.core.Environment.visit(Environment.java:351) at freemarker.core.IteratorBlock.accept(IteratorBlock.java:95) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.process(Environment.java:176) at freemarker.template.Template.process(Template.java:231) at org.hibernate.tool.hbm2x.TemplateHelper.processTemplate(TemplateHelper.java:243) at org.hibernate.tool.hbm2x.TemplateProducer.produceToString(TemplateProducer.java:67) at org.hibernate.tool.hbm2x.TemplateProducer.produce(TemplateProducer.java:28) at org.hibernate.tool.hbm2x.TemplateProducer.produce(TemplateProducer.java:97) at org.hibernate.tool.hbm2x.GenericExporter.exportPOJO(GenericExporter.java:112) at org.hibernate.tool.hbm2x.GenericExporter.exportPersistentClass(GenericExporter.java:101) at org.hibernate.tool.hbm2x.GenericExporter.exportClasses(GenericExporter.java:84) at org.hibernate.tool.hbm2x.GenericExporter.doStart(GenericExporter.java:69) at org.hibernate.tool.hbm2x.AbstractExporter.start(AbstractExporter.java:93) at org.hibernate.tool.hbm2x.GenericExporter.start(GenericExporter.java:59) at org.hibernate.tool.hbm2x.seam.SeamExporter.doStart(SeamExporter.java:65) at org.hibernate.tool.hbm2x.AbstractExporter.start(AbstractExporter.java:93) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate$1.execute(CodeGenerationLaunchDelegate.java:250) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:35) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:68) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.runExporters(CodeGenerationLaunchDelegate.java:221) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.launch(CodeGenerationLaunchDelegate.java:108) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:590) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:515) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:733) at org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:931) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) When you fixed this one you will get the similar error when generates Java sources and hits composite identifier property: !ENTRY org.hibernate.eclipse 1 10000 2006-06-01 09:10:05.689 !MESSAGE DEBUG Worker-0 org.hibernate.tool.hbm2x.TemplateHelper - putInContext pojo=org.hibernate.tool.hbm2x.pojo.ComponentPOJOClass(persistence.data.FlowActionId) !ENTRY org.hibernate.eclipse 1 10000 2006-06-01 09:10:05.690 !MESSAGE DEBUG Worker-0 org.hibernate.tool.hbm2x.TemplateHelper - putInContext clazz=org.hibernate.mapping.Component([org.hibernate.mapping.Property(flowCode), org.hibernate.mapping.Property(actionId)]) !ENTRY org.hibernate.eclipse 4 40000 2006-06-01 09:10:05.693 !MESSAGE ERROR Worker-0 freemarker.runtime - !STACK 0 Expression pojo.identifierProperty is undefined on line 47, column 6 in seam/editorbean.java.ftl. The problematic instruction: ---------- ==> if pojo.identifierProperty.value.identifierGeneratorStrategy == "assigned" [on line 47, column 1 in seam/editorbean.java.ftl] ---------- Java backtrace for programmers: ---------- freemarker.core.InvalidReferenceException: Expression pojo.identifierProperty is undefined on line 47, column 6 in seam/editorbean.java.ftl. at freemarker.core.TemplateObject.assertNonNull(TemplateObject.java:124) at freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:134) at freemarker.core.Dot._getAsTemplateModel(Dot.java:78) at freemarker.core.Expression.getAsTemplateModel(Expression.java:89) at freemarker.core.Dot._getAsTemplateModel(Dot.java:74) at freemarker.core.Expression.getAsTemplateModel(Expression.java:89) at freemarker.core.ComparisonExpression.isTrue(ComparisonExpression.java:111) at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:77) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.visit(Environment.java:233) at freemarker.core.BlockAssignment.accept(BlockAssignment.java:83) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.process(Environment.java:176) at freemarker.template.Template.process(Template.java:231) at org.hibernate.tool.hbm2x.TemplateHelper.processTemplate(TemplateHelper.java:243) at org.hibernate.tool.hbm2x.TemplateProducer.produceToString(TemplateProducer.java:67) at org.hibernate.tool.hbm2x.TemplateProducer.produce(TemplateProducer.java:28) at org.hibernate.tool.hbm2x.TemplateProducer.produce(TemplateProducer.java:97) at org.hibernate.tool.hbm2x.GenericExporter.exportPOJO(GenericExporter.java:112) at org.hibernate.tool.hbm2x.GenericExporter.exportComponent(GenericExporter.java:97) at org.hibernate.tool.hbm2x.GenericExporter.exportClasses(GenericExporter.java:91) at org.hibernate.tool.hbm2x.GenericExporter.doStart(GenericExporter.java:69) at org.hibernate.tool.hbm2x.AbstractExporter.start(AbstractExporter.java:93) at org.hibernate.tool.hbm2x.GenericExporter.start(GenericExporter.java:59) at org.hibernate.tool.hbm2x.seam.SeamExporter.doStart(SeamExporter.java:83) at org.hibernate.tool.hbm2x.AbstractExporter.start(AbstractExporter.java:93) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate$1.execute(CodeGenerationLaunchDelegate.java:250) at org.hibernate.console.execution.DefaultExecutionContext.execute(DefaultExecutionContext.java:35) at org.hibernate.console.ConsoleConfiguration.execute(ConsoleConfiguration.java:68) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.runExporters(CodeGenerationLaunchDelegate.java:221) at org.hibernate.eclipse.launch.CodeGenerationLaunchDelegate.launch(CodeGenerationLaunchDelegate.java:108) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:590) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:515) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:733) at org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:931) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Steve E. (JIRA) <no...@at...> - 2006-06-01 11:55:19
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23226 ] Steve Ebersole commented on HHH-1808: ------------------------------------- That or you could follow the best practices for this stuff set forth in both the Hibernate documentation and JPA spec which states not to perform bulk operations (executeUpdate()) from sessions/persistence-contexts already containing state. I vote the later... > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 11:53:19
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23227 ] Thomas Boerkel commented on HHH-1808: ------------------------------------- Sometimes, you have to do "normal" and bulk operations in the same transaction. > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 11:31:36
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=comments#action_23225 ] Thomas Boerkel commented on HHH-1808: ------------------------------------- Then at least there should be an overloaded evict() method, that takes for example the name of an entity (in my example, "events.Person"), that would evict all objects from that type. > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Christian B. (JIRA) <no...@at...> - 2006-06-01 10:26:17
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ] Christian Bauer resolved HHH-1808: ---------------------------------- Resolution: Rejected This is the documented and standardized behavior of the bulk operations... > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 10:18:28
|
Session cache is not being invalidated by executeUpdate() --------------------------------------------------------- Key: HHH-1808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate 3.1.3 and 3.2.0.cr2 MS SQL Server 2000 ehCache Reporter: Thomas Boerkel Attachments: hibernate.log, src.zip When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). Example builds on Hibernate tutorial. First, we create and then alter an object: Long personId = mgr.createAndStorePerson("Vor", "Nach"); Session session = HibernateUtil.getSessionFactory().getCurrentSession(); session.beginTransaction(); Person person1 = (Person)session.load(Person.class, personId); person1.setAge(10); session.save(person1); session.flush(); Then, in the same session, we execute an update: session.createQuery("update Person set age = 20").executeUpdate(); Then, we load() again: Person person2 = (Person)session.load(Person.class, personId); System.out.println(person2.getAge()); session.getTransaction().commit(); This prints 10 instead of 20. If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: session = HibernateUtil.getSessionFactory().getCurrentSession(); session.beginTransaction(); Person person3 = (Person)session.load(Person.class, personId); System.out.println(person3.getAge()); session.getTransaction().commit(); So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: for(Object o : session.getStatistics().getEntityKeys()) { EntityKey key = (EntityKey) o; if(key.getEntityName().equals("events.Person")) { session.evict(session.load(key.getEntityName(), key.getIdentifier())); } } And this is pretty involved and for sure not fast vor many objects. The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). You may say, the current behavior is by design and documented, but I still think, this is a big problem. Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 10:18:28
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ] Thomas Boerkel updated HHH-1808: -------------------------------- Attachment: hibernate.log Logfile > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Thomas B. (JIRA) <no...@at...> - 2006-06-01 10:18:18
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808?page=all ] Thomas Boerkel updated HHH-1808: -------------------------------- Attachment: src.zip Repro > Session cache is not being invalidated by executeUpdate() > --------------------------------------------------------- > > Key: HHH-1808 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1808 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2 > Environment: Hibernate 3.1.3 and 3.2.0.cr2 > MS SQL Server 2000 > ehCache > Reporter: Thomas Boerkel > Attachments: hibernate.log, src.zip > > > When I do executeUpdate() (either HQL or native SQL with 3.2), the 2nd level cache gets invalidated for the target table, but (now obsolete) objects remain in the session cache and are being delivered by load(). > Example builds on Hibernate tutorial. > First, we create and then alter an object: > Long personId = mgr.createAndStorePerson("Vor", "Nach"); > > Session session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person1 = (Person)session.load(Person.class, personId); > person1.setAge(10); > session.save(person1); > session.flush(); > Then, in the same session, we execute an update: > session.createQuery("update Person set age = 20").executeUpdate(); > Then, we load() again: > Person person2 = (Person)session.load(Person.class, personId); > System.out.println(person2.getAge()); > session.getTransaction().commit(); > This prints 10 instead of 20. > If we load() again in a NEW session, then the object is fetched from the DB, not from ehCache, which is correct: > session = HibernateUtil.getSessionFactory().getCurrentSession(); > session.beginTransaction(); > > Person person3 = (Person)session.load(Person.class, personId); > System.out.println(person3.getAge()); > > session.getTransaction().commit(); > So, the 2nd level cache is AUTOMATICALLY invalidated from the executeUpdate(), but to invalidate the session cache, you have to clear() everything or to evict() each and every object by hand. This is simple in this small example, but in a real application, you have to do: > for(Object o : session.getStatistics().getEntityKeys()) { > EntityKey key = (EntityKey) o; > if(key.getEntityName().equals("events.Person")) { > session.evict(session.load(key.getEntityName(), key.getIdentifier())); > } > } > And this is pretty involved and for sure not fast vor many objects. > The right thing would be, that Hibernate automatically evicts() all objects from the target table from the session cache, if that table is being altered by an executeUpdate(). > You may say, the current behavior is by design and documented, but I still think, this is a big problem. > Attaching hibernate.log and src. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Jaroslaw O. (JIRA) <no...@at...> - 2006-06-01 09:18:20
|
For SQLServerDialect varbinary sql-type is generated for Serializable objects ----------------------------------------------------------------------------- Key: HHH-1807 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1807 Project: Hibernate3 Type: Bug Versions: 3.1.3 Environment: Hibernate 3.1.3, SQLServer Reporter: Jaroslaw Odzga The schema export generates "varbinary(xxx)" if the mapping document specifies "serializable" for a particular field. In SQL server varbinary has a limit of 8000 bytes (less if there is more data on the row). In order to store more than this, the data type should to be "IMAGE" instead of "varbinary(xxx)". This problem has already been investigated: http://forum.hibernate.org/viewtopic.php?t=933683 The resolution has been proposed and applied by simply changing the SQLServerDialect where two lines: registerColumnType( Types.VARBINARY, "image" ); registerColumnType( Types.VARBINARY, 8000, "varbinary($l)" ); has been added to the constructor. However this solution does not work properly. Here is example: example.hibernate.Person.java file: package example.hibernate; import java.io.Serializable; /** * @hibernate.class */ public class Person { private Serializable attributes; private Long PersonId; /** * @hibernate.id * generator-class="hilo" */ public Long getPersonId() { return PersonId; } public void setPersonId(Long personId) { PersonId = personId; } /** * @hibernate.property */ public Serializable getAttributes() { return attributes; } public void setAttributes(Serializable attributes) { this.attributes = attributes; } } generated mapping by xdoclet: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping> <class name="example.hibernate.Person"> <id name="personId" column="personId" type="java.lang.Long"> <generator class="hilo"> </generator> </id> <property name="attributes" type="java.io.Serializable" update="true" insert="true" column="attributes" /> </class> </hibernate-mapping> and the generated sql script by schema export: create table Person (personId numeric(19,0) not null, attributes varbinary(255) null, primary key (personId)); create table hibernate_unique_key ( next_hi int ); insert into hibernate_unique_key values ( 0 ); After investigating data types definition I came up with the following sollution: replace registerColumnType( Types.VARBINARY, 8000, "varbinary($l)" ); with registerColumnType( Types.VARBINARY, 8000, "image" ); Works fine now but I think maybe there is a better way - simply force Hibernate to use VARBINARY without specified size in case of Serializable objects. Also, shouldn't be super(); the first line of SQLServerDialect constructor? -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: amit b. (JIRA) <no...@at...> - 2006-06-01 06:41:21
|
No Dialect mapping for JDBC type: 3 ----------------------------------- Key: HHH-1806 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1806 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.2, 3.1.3 Environment: Oracle JDBC driver with the Hibernate DataDirectOracle9Dialect. Reporter: amit bhayani Hibernate throws "No Dialect mapping for JDBC type: 3" when using Oracle JDBC driver with the Hibernate DataDirectOracle9Dialect. DataDirect Connect for JDBC Oracle driver returns the JDBC type DECIMAL for some result set columns however there was no mapping set up in the DataDirectOracle9Dialect for the DECIMAL JDBC type. The work arround for issue is to add the following constructor to DataDirectOracle9Dialect public DataDirectOracle9Dialect() { super(); registerColumnType( Types.DECIMAL, "number($p,$s)" ); registerHibernateType(Types.DECIMAL, "big_decimal"); } Can Hibernate Team add this constructor or something similar to the DataDirectOracle9Dialect? Version Info Hibernate: 3.1.3 DataDirect Connect for JDBC Oracle driver: 3.5.40 Forum reference http://forum.hibernate.org/viewtopic.php?t=959583&highlight=dialect+mapping+jdbc+type+3 -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Igor A T. (JIRA) <no...@at...> - 2006-06-01 01:48:21
|
Incorrect query parsing cause NullPointerException -------------------------------------------------- Key: HHH-1805 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1805 Project: Hibernate3 Type: Bug Components: query-hql Versions: 3.2.0.cr2 Reporter: Igor A Tarasov Incorrect HQL query (without AS object) cause NullPointerException Incorrect: "select o from MyObject where o.name = ?1" Correct: "select o from MyObject as o where o.name = ?1" The next code with incorrect query cause NullPointerException: em.createQuery("select o from MyObject where o.name = ?1").setParameter(1, "some_name").getResultList(); java.lang.NullPointerException at org.hibernate.hql.ast.tree.IdentNode.resolveAsNakedComponentPropertyRefLHS(IdentNode.java:195) at org.hibernate.hql.ast.tree.IdentNode.resolve(IdentNode.java:85) at org.hibernate.hql.ast.tree.DotNode.resolveFirstChild(DotNode.java:139) at org.hibernate.hql.ast.HqlSqlWalker.lookupProperty(HqlSqlWalker.java:469) at org.hibernate.hql.antlr.HqlSqlBaseWalker.addrExpr(HqlSqlBaseWalker.java:4316) at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1211) at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032) at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3880) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683) at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776) at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:577) at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281) at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229) at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:227) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:159) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1612) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:76) at org.dicr.isp.data.HibernateDataManager.createConnection(HibernateDataManager.java:696) -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Maarten W. (JIRA) <no...@at...> - 2006-06-01 00:44:19
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804?page=all ] Maarten Winkels updated HHH-1804: --------------------------------- Attachment: scroll-join-fetch-empty.patch This patch resolves the problem by checking the result set on the first invocation of 'next()'. > Empty 'FetchingScrollableResultsImpl' throws SQLException > --------------------------------------------------------- > > Key: HHH-1804 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804 > Project: Hibernate3 > Type: Bug > Reporter: Maarten Winkels > Attachments: EmptyFetchJoinScrollTest.java, scroll-join-fetch-empty.patch > > > When scrolling a HQL query with join fetch on a collection, that doesn't return any results, the following execption occurs: > org.hibernate.exception.GenericJDBCException: could not perform sequential read of results (forward) > at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:386) > at org.hibernate.impl.FetchingScrollableResultsImpl.next(FetchingScrollableResultsImpl.java:55) > at org.hibernate.test.joinfetch.EmptyFetchJoinScrollTest.testFetchJoinEmptyScroll(EmptyFetchJoinScrollTest.java:21) > 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 junit.framework.TestCase.runTest(TestCase.java:154) > at org.hibernate.test.TestCase.runTest(TestCase.java:161) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: java.sql.SQLException: No data is available > at org.hsqldb.jdbc.Util.sqlException(Unknown Source) > at org.hsqldb.jdbc.Util.sqlException(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.checkAvailable(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getColumnInType(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) > at org.hibernate.type.StringType.get(StringType.java:18) > at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:113) > at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:102) > at org.hibernate.loader.Loader.getKeyFromResultSet(Loader.java:1088) > at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:375) > ... 18 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Maarten W. (JIRA) <no...@at...> - 2006-06-01 00:38:19
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804?page=all ] Maarten Winkels updated HHH-1804: --------------------------------- Attachment: EmptyFetchJoinScrollTest.java Testcase that shows the exception. > Empty 'FetchingScrollableResultsImpl' throws SQLException > --------------------------------------------------------- > > Key: HHH-1804 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804 > Project: Hibernate3 > Type: Bug > Reporter: Maarten Winkels > Attachments: EmptyFetchJoinScrollTest.java > > > When scrolling a HQL query with join fetch on a collection, that doesn't return any results, the following execption occurs: > org.hibernate.exception.GenericJDBCException: could not perform sequential read of results (forward) > at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:386) > at org.hibernate.impl.FetchingScrollableResultsImpl.next(FetchingScrollableResultsImpl.java:55) > at org.hibernate.test.joinfetch.EmptyFetchJoinScrollTest.testFetchJoinEmptyScroll(EmptyFetchJoinScrollTest.java:21) > 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 junit.framework.TestCase.runTest(TestCase.java:154) > at org.hibernate.test.TestCase.runTest(TestCase.java:161) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > Caused by: java.sql.SQLException: No data is available > at org.hsqldb.jdbc.Util.sqlException(Unknown Source) > at org.hsqldb.jdbc.Util.sqlException(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.checkAvailable(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getColumnInType(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) > at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) > at org.hibernate.type.StringType.get(StringType.java:18) > at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:113) > at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:102) > at org.hibernate.loader.Loader.getKeyFromResultSet(Loader.java:1088) > at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:375) > ... 18 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Maarten W. (JIRA) <no...@at...> - 2006-06-01 00:36:21
|
Empty 'FetchingScrollableResultsImpl' throws SQLException --------------------------------------------------------- Key: HHH-1804 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1804 Project: Hibernate3 Type: Bug Reporter: Maarten Winkels When scrolling a HQL query with join fetch on a collection, that doesn't return any results, the following execption occurs: org.hibernate.exception.GenericJDBCException: could not perform sequential read of results (forward) at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:386) at org.hibernate.impl.FetchingScrollableResultsImpl.next(FetchingScrollableResultsImpl.java:55) at org.hibernate.test.joinfetch.EmptyFetchJoinScrollTest.testFetchJoinEmptyScroll(EmptyFetchJoinScrollTest.java:21) 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 junit.framework.TestCase.runTest(TestCase.java:154) at org.hibernate.test.TestCase.runTest(TestCase.java:161) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.sql.SQLException: No data is available at org.hsqldb.jdbc.Util.sqlException(Unknown Source) at org.hsqldb.jdbc.Util.sqlException(Unknown Source) at org.hsqldb.jdbc.jdbcResultSet.checkAvailable(Unknown Source) at org.hsqldb.jdbc.jdbcResultSet.getColumnInType(Unknown Source) at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) at org.hsqldb.jdbc.jdbcResultSet.getString(Unknown Source) at org.hibernate.type.StringType.get(StringType.java:18) at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:113) at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:102) at org.hibernate.loader.Loader.getKeyFromResultSet(Loader.java:1088) at org.hibernate.loader.Loader.loadSequentialRowsForward(Loader.java:375) ... 18 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Maarten W. (JIRA) <no...@at...> - 2006-05-31 23:06:20
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1803?page=all ] Maarten Winkels updated HHH-1803: --------------------------------- Attachment: criteria-scroll-fetch-collection.patch This (incremental) patch solves the problem. Apply the patch in the linked issue first. > Allow fetching with criteria when scrolling > ------------------------------------------- > > Key: HHH-1803 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1803 > Project: Hibernate3 > Type: Improvement > Components: query-criteria > Versions: 3.2.0.cr2 > Reporter: Maarten Winkels > Attachments: Child.java, CriteriaScrollFetchTest.java, Parent.java, ParentChild.hbm.xml, criteria-scroll-fetch-collection.patch > > > When querying by criteria, fetching is allowed, but when scrolling a criteria, the fetching corrupts the result. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Maarten W. (JIRA) <no...@at...> - 2006-05-31 22:53:16
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1803?page=all ] Maarten Winkels updated HHH-1803: --------------------------------- Attachment: CriteriaScrollFetchTest.java Parent.java Child.java This testcase shows the problem. (Apply the patch in the linked issue!) > Allow fetching with criteria when scrolling > ------------------------------------------- > > Key: HHH-1803 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1803 > Project: Hibernate3 > Type: Improvement > Components: query-criteria > Versions: 3.2.0.cr2 > Reporter: Maarten Winkels > Attachments: Child.java, CriteriaScrollFetchTest.java, Parent.java, ParentChild.hbm.xml > > > When querying by criteria, fetching is allowed, but when scrolling a criteria, the fetching corrupts the result. -- 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.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |