[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, 5 months
[Hibernate-JIRA] Created: (HHH-3075) Should be possible to register UserTypes for known property types (classes) in configuration
by Martin Probst (JIRA)
Should be possible to register UserTypes for known property types (classes) in configuration
--------------------------------------------------------------------------------------------
Key: HHH-3075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3075
Project: Hibernate3
Issue Type: Improvement
Components: core
Environment: n/a
Reporter: Martin Probst
Priority: Minor
Currently, when persisting primitive properties of a class that are not known to Hibernate, there are only cumbersome ways to tell Hibernate that a certain UserType should be used. Good example is Joda Time:
<pre>
@Entity
class MyClass {
org.joda.time.DateTime foo;
}
</pre>
.. which will result in ugly binary fields in database. Next try:
<pre>
@Entity
class MyClass {
@Type(type = "org.joda.time.contrib.hibernate.PersistentDateTime")
org.joda.time.DateTime foo;
}
</pre>
That works, but now I have to specify that on all time fields of all classes. Plus it's different types for different classes, which makes it more messy. And it's simply a string in code, so it's fragile to refactoring, code move, etc. TypeDefs allow a shorter handle for certain types, but don't really address the refactoring issues.
A better way might be to allow configurations to register UserTypes for known classes. E.g. have a configuration directive like this:
<mappable-type class="org.joda.time.DateTime" usertype="org.joda.time.hibernate.DateTimeType"/>
This would allow the classes to stay clean from type mappings and reduce coupling between domain objects and persistence mapping.
This might be as easy as allowing the org.hibernate.type.TypeFactory map to be extended at configuration time.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[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, 5 months
[Hibernate-JIRA] Created: (ANN-846) Infinite loop occurs while doing findById on a Parent domain Object having OneToMany relationship with child domain with composite primary key
by RAMESH BABU NL (JIRA)
Infinite loop occurs while doing findById on a Parent domain Object having OneToMany relationship with child domain with composite primary key
----------------------------------------------------------------------------------------------------------------------------------------------
Key: ANN-846
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-846
Project: Hibernate Annotations
Issue Type: Improvement
Affects Versions: 3.4.0.GA
Environment: Hibernate Annotations 3.4.0.GA, HSqlDB and Oracle
Reporter: RAMESH BABU NL
Attachments: Organization.java, OrganizationApplications.java, OrganizationApplicationsPK.java
We are using Hibernate annotations version 3.4.0.G.A
We are establishing a OneToMany relationship using the annotation @OnetoMany for a Parent and Child domain objects
where the child domain has a composite primary key.
We have two domain objects
Organization [Parent]
OrganizationApplications [Child]
We want to have a OnetoMany relationship between Organization and OrganizationApplications.
As shown below OrganizationApplications contains a composite primary key, of two columns(Organization Id, ApplicationId[foreignkey from other table called APPLICATIONS])
Organizations.java
-------------------
@OneToMany(targetEntity=gov.osc.enrollment.backend.domain.OrganizationApplications.class, cascade=CascadeType.ALL, fetch = FetchType.EAGER,
mappedBy="id.organization")
private Set<OrganizationApplications> organizationApps = new HashSet<OrganizationApplications>();
OrganizationApplications.java
---------------------------------------------------------------------
public class OrganizationApplications extends EnvelopeInfo implements Serializable {
private static final long serialVersionUID = 1L;
@EmbeddedId
private OrganizationApplicationsPK id;
public OrganizationApplicationsPK getId() {
return id;
}
public void setId(OrganizationApplicationsPK id) {
this.id = id;
}
OrganizationApplicationsPK.java
---------------------------------------------------------------------
@Embeddable
public class OrganizationApplicationsPK implements Serializable {
private static final Long serialVersionUID = 1L;
public OrganizationApplicationsPK() {
super();
}
@ManyToOne
@JoinColumn(name="APPLICATION_ID",nullable=false)
private Applications application;
@ManyToOne(targetEntity=gov.osc.enrollment.backend.domain.Organization.class, cascade=CascadeType.ALL)
@JoinColumn(name="ORGANIZATION_ID", referencedColumnName="ORGANIZATION_ID", nullable=false, insertable=true, updatable=true)
private Organization organization;
public Applications getApplication() {
return application;
}
public void setApplication(Applications application) {
this.application = application;
}
public Organization getOrganization() {
return organization;
}
public void setOrganization(Organization organization) {
this.organization = organization;
}
@Override
public boolean equals(Object o) {
if (o == this) {
return true;
}
if ( ! (o instanceof OrganizationApplicationsPK)) {
return false;
}
OrganizationApplicationsPK other = (OrganizationApplicationsPK) o;
return (this.getOrganization().getId() == other.getOrganization().getId())
&& (this.getApplication().getId() == other.getApplication().getId());
}
@Override
public int hashCode() {
final int prime = 31;
int hash = 17;
hash = hash * prime + ((int) (this.getOrganization().getId() ^ (this.getOrganization().getId() >>> 32)));
hash = hash * prime + ((int) (this.getApplication().getId() ^ (this.getApplication().getId() >>> 32)));
return hash;
}
}
Please see the attached java files for complete code and also the exception stack trace.
Questions:
1. When we do a findById query on Organization table the system goes into infinite loop and never gets out .
How ever we are able to insert a record in Organization and its child OrganizationApplications.
2. In the Organization.java domain, if you notice we are using mappedby="id.organization". Is this a valid mapping ?
If not why does this parameter work for insert and not for a entityManager.findById, doing so leads to infinite loop.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months