[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections
by Justin Haddad (JIRA)
Deleted object remains referenced in 2nd level cache collections
----------------------------------------------------------------
Key: HHH-1989
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3
Reporter: Justin Haddad
This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object):
aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101)
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:1705)
(continues on)
I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion.
--
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
[Hibernate-JIRA] Created: (HHH-2645) Synchronization bottleneck in EntityModeToTuplizerMapping
by Erik Bergersjö (JIRA)
Synchronization bottleneck in EntityModeToTuplizerMapping
---------------------------------------------------------
Key: HHH-2645
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2645
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.3 (and later), Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10, Oracle 10g R2
Reporter: Erik Bergersjö
Priority: Minor
We have had a major performance bottleneck in EntityModeToTuplizerMapping with Hibernate version 3.2.3 and the code for that class in 3.2.4sp1 is unchanged. We have found a solution that solves the issue and would like to get it into the real version. I submitted to the user forum first and was asked to create a JIRA issue.
The problematic line is:
private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() );
We have changed it to (using util.concurrent):
private final Map tuplizers = new EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap();
This change alone makes our use cases six times faster. The difference is that ConcurrentReaderHashMap handles concurrent readers much better, they don't have to wait for each other.
The problem occurs when a high number of threads try to initialize sets (see mapping below). A thread dump showed a high number of threads waiting for the same monitor, see partial stack trace below.
The code runs on Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10 and the kernel spends a lot of time handling mutexes with the original implementation. That time disappears from the radar screen with the fixed version.
Example mapping for set:
[code]
<set name="lines" lazy="true" inverse="true" cascade="all-delete-orphan">
<key>
<column name="col1" not-null="true" />
<column name="col2" not-null="true" />
</key>
<one-to-many class="LineClass" />
</set>
[/code]
Stack trace (partial):
"Thread-108" prio=5 tid=0x05852e90 nid=0x103 waiting for monitor entry [0x3ed7e000..0x3ed7fc28]
at java.util.Collections$SynchronizedMap.get(Collections.java:1942)
- waiting to lock <0x89d30788> (a java.util.Collections$SynchronizedMap)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizerOrNull(EntityModeToTuplizerMapping.java:53)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizer(EntityModeToTuplizerMapping.java:66)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353)
at org.hibernate.type.ComponentType.isEqual(ComponentType.java:141)
at org.hibernate.engine.CollectionKey.equals(CollectionKey.java:50)
at java.util.HashMap.eq(HashMap.java:274)
at java.util.HashMap.get(HashMap.java:323)
at org.hibernate.engine.loading.CollectionLoadContext.getLocalLoadingCollectionEntry(CollectionLoadContext.java:163)
at org.hibernate.engine.loading.CollectionLoadContext.locateLoadingCollectionEntry(CollectionLoadContext.java:150)
at org.hibernate.engine.loading.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:92)
at org.hibernate.loader.Loader.readCollectionElement(Loader.java:1003)
at org.hibernate.loader.Loader.readCollectionElements(Loader.java:646)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:591)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1994)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentSet.iterator(PersistentSet.java:163)
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-2041) Update with unaltered natural-id fails
by Jim Pease (JIRA)
Update with unaltered natural-id fails
--------------------------------------
Key: HHH-2041
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2041
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: hibernate-3.1.3, mysql-4.1.12
Reporter: Jim Pease
This may be a duplicate of http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574.
Getting following error:
caused by: org.hibernate.HibernateException: immutable natural identifier of an instance of edu.syr.lsb.gmt.impl.LinkImpl was altered
at org.hibernate.event.def.DefaultFlushEntityEventListener.checkNaturalId(DefaultFlushEntityEventListener.java:80)
at org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:155)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:106)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:195)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
...
This is occurring without modifications to the natural identifier, which is mapped as follows:
<natural-id>
<property name="activityRef" column="ACTIVITY_REF" length="255" not-null="true" />
<many-to-one name="goal" class="GoalImpl" column="GOAL_ID" not-null="true" cascade="none" />
</natural-id>
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-2584) PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map
by Daniel Wellman (JIRA)
PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map
---------------------------------------------------------------------
Key: HHH-2584
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.3, 3.2.2, 3.2.1
Environment: Hibernate 3.2.3 ga, MySQL 5.0.24a, for Win32
Reporter: Daniel Wellman
Attachments: persistentmap_remove.patch
This problem is nearly identical to HHH-2476: PersistentMap.put() incorrect on uninitialized, non-extra-lazy map. remove() has the same problem. See also issue HHH-2142.
The write up for HHH-2476 was so concise that I will transform it here, substituting remove() for put().
---
Essentially, an uninitialized PersistentMap loses the first remove() into it if defined as non-extra-lazy.
The underlying cause is the code in PersistentMap#remove() which attempts to readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the UNKNOWN marker object which is supposed to be used to signal that the delegate map is now initialized and to remove the element directly from the map. Long story short, PersistentMap#remove() does not properly check the return value from readElementByIndex() and react accordingly.
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-2295) entity-name attribute's syntax not clearly documented
by Jeremy Michael Crosbie (JIRA)
entity-name attribute's syntax not clearly documented
-----------------------------------------------------
Key: HHH-2295
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2295
Project: Hibernate3
Type: Bug
Components: documentation
Versions: 3.2.1
Environment: Windows XP/JDK 1.5/HypersonicSQL
Reporter: Jeremy Michael Crosbie
Priority: Minor
Attachments: Group.hbm.xml
Setting entity-name to a value containing a hyphen, in my case 'lender-group' causes odd behaviors seemingly only when calling get() or load(). Also in my case I am mapping a class to two different tables (attached). The first mapping has an entity name with a hyphen, the other does not. When I call load *after committing a transaction where a new entity is persisted* I get an exception (see below). The exception complains of a column called "LENDER" not existing. But once I change the entity-name to something like 'lendergroup' the problem goes away. Interestingly, the missing column complained about is the text before the hyphen, so if I name the entity 'lndr-group' it complains of a column name 'LNDR' not existing.
It almost appears if this format is assuming some sort of discriminator, but the online docs are terse when it comes to describing the entity-name field.
Exception:
org.hibernate.exception.SQLGrammarException: could not load an entity: [lender-group#G9]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1799)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301)
at $Proxy0.get(Unknown Source)
at com.fares.mtrac.group.GroupDaoImpl.findById(GroupDaoImpl.java:148)
at com.fares.mtrac.group.GroupDaoImplTest.testFindByIdStringCompanyType(GroupDaoImplTest.java:256)
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:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
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:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.sql.SQLException: Column not found: LENDER in statement [select lender-gro0_.group_cd as group1_48_0_, lender-gro0_.group_nm as group2_48_0_, lender-gro0_.user_nm as user3_48_0_ from lender_group_name lender-gro0_ where lender-gro0_.group_cd=?]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:442)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:368)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:105)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
at org.hibernate.loader.Loader.doQuery(Loader.java:661)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
... 36 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (HHH-2679) One to Many Unidirectional Association using Join Tables and <list> causes duplicate key constraint violation when an entry is deleted from the list.
by Priyajeet Hora (JIRA)
One to Many Unidirectional Association using Join Tables and <list> causes duplicate key constraint violation when an entry is deleted from the list.
-----------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2679
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2679
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Environment: Java 1.5, Hibernate 3.2, MySQL 5. Might also effect NHibernate similarly.
Reporter: Priyajeet Hora
Priority: Critical
Consider this unidirectional one-to-many relation done using join tables.
Person --> Address (*).
The hibernate mapping is pretty much the same as
http://www.hibernate.org/hib_docs/v3/reference/en/html/associations.html#...
Though I am using <list> rather than a <set>
Following is the DDL (presented roughly) created by the hbm2ddl tool.
Table PersonAddress
Person_id varcahr not null
Address_id varchar not null unique
Person_list_index integer not null
primary key (Person_id, Person_list_index)
I create a person1 - person_id=1.
I create add1, add2, add3 - address_id=2,3,4 respectively.
then I add all 3 addresses to the list in person1.
persist it to database.
all good.
At this point in the database --
person_id---person_list_index---address_id
1--0--2
1--1--3
1--2--4
I get person1 back.
I remove add1.
save person1 back.
CONSTRIANT VIOLATION HERE DUE TO DUPLICATE KEY.
looking at what hibernate does ...
So after 1st save and before remove this is whats in the database -
person_id---person_list_index---address_id
1--0--2
1--1--3
1--2--4
basically shows the one to many there.
I want to remove the record no. 1--0--2. That is the 1st one.
So with the 1st row gone, hibernate needs to shift other records up so that the new list index is assingned.
expected output----
1--0--3
1--1--4
This is how hibernate proceeds
Step1: save info and delete on 1--2--4, to get rid of that last record.
Step2: update 1--0--2 to 1--0--3
BANG...CONSTRAINT VIOLATION DUE TO DUPLICATE KEY.
Why? because "3" in that address_id column is already there and that column is "unique" according to DDL.
Step3: update 1--0--3 to info saved from step1, that is to 1--1--4.
But cant persist this since step 2 fails.
Basically the algorithm of copy the value up when a delete is performed is not doing the copy correctly.
Way to get around this is to remove the "unique" constrint, but then that makes the relation a many to many.
-----------------------------------------------------------------------------
CREATE TABLE `PERSON`
(
`PRESON_ID` varchar(255) NOT NULL, PRIMARY KEY (PRESON_ID)
)
CREATE TABLE `ADDRESS`
(
`ADDRESS_ID` varchar(255) NOT NULL, PRIMARY KEY (ADDRESS_ID)
)
CREATE TABLE `PERSONADDRESS`
(
`PERSON_ID` varchar(255) NOT NULL
, `PERSON_IDX` integer NOT NULL
, `ADDRESS_ID` varchar(255) NOT NULL UNIQUE, PRIMARY KEY (PERSON_ID, PERSON_IDX)
)
ALTER TABLE `PERSONADDRESS`
ADD INDEX `PERSONADDRESS_FK_PERSON` (`PERSON_ID`),
ADD CONSTRAINT `PERSONADDRESS_FK_PERSON`
FOREIGN KEY (`PERSON_ID`)
REFERENCES PERSON(`PERSON_ID`)
ALTER TABLE `PERSONADDRESS`
ADD INDEX `PERSONADDRESS_FK_ADDRESS` (`ADDRESS_ID`),
ADD CONSTRAINT `PERSONADDRESS_FK_ADDRESS`
FOREIGN KEY (`ADDRESS_ID`)
REFERENCES ADDRESS(`ADDRESS_ID`)
Person.hbm.xml
-------------------------
<list name="AddressList" lazy="false" table="PersonAddress">
<key column="PERSON_ID" />
<index column="PERSON_IDX" />
<many-to-many column="ADDRESS_ID" unique="true" class="Address" />
</list>
Address.hbm.xml
--------------------------
No information about Person, since this is a unidirectional association.
Target doesnt know about the source.
Test psuedocode
-------------------------
//start transaction
Person person = new Person();
Address add1 = new Address();
Address add2 = new Address();
Address add3 = new Address();
person.add(add1);
person.add(add2);
person.add(add3);
// persist to database
person.save
// end transaction
// start transaction
// get back that person from database
person.remove(add1);
// persist to database
person.save <<<<<<<<<<<<<<< FAILS, duplicate key constraint violation
// end transaction
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-2341) ObjectNotFoundException on session.get() on non-existent object
by Timo Thomas (JIRA)
ObjectNotFoundException on session.get() on non-existent object
---------------------------------------------------------------
Key: HHH-2341
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2341
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: HSQLDB 1.8.0
Reporter: Timo Thomas
Hibernate version:
3.2.1 GA (same for hibernate-annotations)
Mapping documents:
Parent.java (omitting package and some import declarations)
import javax.persistence.*;
@Entity
public class Parent {
public Integer id;
public Set<Child> children = new HashSet<Child>();
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL)
public Set<Child> getChildren() {
return children;
}
public void setChildren(Set<Child> children) {
this.children = children;
}
}
Child.java (omitting package and some import declarations)
import javax.persistence.*;
@Entity
public class Child {
public Integer id;
public Parent parent;
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
@ManyToOne(optional = false)
@JoinColumn(name = "parent_fk")
public Parent getParent() {
return parent;
}
public void setParent(Parent parent) {
this.parent = parent;
}
}
Code between sessionFactory.openSession() and session.close():
Transaction transaction = session.beginTransaction();
Parent parent = new Parent();
parent.setName("p1");
session.persist(parent);
assertNotNull(parent.getId());
Integer parentId = parent.getId();
Child child = new Child();
child.setName("c1");
child.setParent(parent);
parent.getChildren().add(child);
session.persist(parent);
assertNotNull(child.getId());
Integer childId = child.getId();
transaction.commit();
session.close();
///////////////////////////////////////////
session = sessionFactory.openSession();
transaction = session.beginTransaction();
parent = (Parent) session.load(Parent.class, parentId);
child = (Child) session.load(Child.class, childId);
// child = (Child) session.get(Child.class, childId);
session.delete(parent);
// session.flush(); // !! required if session&transaction is re-opened and child is obtained with load(), otherwise exception on next line - BUG ?
child = (Child) session.get(Child.class, childId);
Full stack trace of any exception that occurs:
org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [model.Child#1]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:375)
at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:223)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:187)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
at test.CascadeAnnotationTest.testBug(CascadeAnnotationTest.java:48)
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:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
The generated SQL (show_sql=true):
Hibernate: insert into Parent (id, name) values (null, ?)
Hibernate: call identity()
Hibernate: insert into Child (id, name, parent_fk) values (null, ?, ?)
Hibernate: call identity()
Hibernate: select parent0_.id as id0_0_, parent0_.name as name0_0_ from Parent parent0_ where parent0_.id=?
Hibernate: select children0_.parent_fk as parent3_1_, children0_.id as id1_, children0_.id as id1_0_, children0_.name as name1_0_, children0_.parent_fk as parent3_1_0_ from Child children0_ where children0_.parent_fk=?
Why is this exception thrown under these circumstances? Am I using the API in an undocumented/disallowed way? If yes, where exactly?
The Hibernate API doc says, that Session.get() returns null if an object can't be found. No exception should be thrown.
However, Session.get() at the end of sample code does return null as expected, if either
a) Session.get() is used instead of load() some lines above (see commented line)
b) the transaction and the session is isn't closed or reopened, respectively
c) Session.flush() is called before the final call to Session.get()
I'd like to understand why Hibernate behaves like this, which I presume is erroneous. I'm a beginner in Hibernate, but I couldn't get any help in the forum.
Timo
--
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, 3 months