[Hibernate-JIRA] Created: (HHH-3544) Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled
by Jeppe Cramon (JIRA)
Nullability.checkNullability() throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences() just nulled
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3544
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3544
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1, Hibernate Annotations 3.4, Hibernate Commons-Annotation 3.3.1, Hibernate EntityManager 3.4, PostgreSQL 8.2.5, Java 5
Reporter: Jeppe Cramon
Attachments: HibernateNullabilityProblem.zip
Nullability.checkNullability throws PropertyValueException (not-null property references a null property) for a property that ForeignKeys.Nullifier.nullifyTransientReferences just nulled.
I've included an Eclipse Java project which can reproduce the problem (didn't include the jars).
The problem requires a pretty big graph to be reproduce able. The file "Domain Model.jpg" displays the Classes that take part in the problem.
The Domain Model is a simplification of the entities from our application.
In the example, ModelTest.java, there's only one active instance entity of each type (from A to H).
With the given test case, when an instance of a is passed to entityManager.persist(..), then the following exception is thrown:
javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:226)
at dk.hibernatetest.model.ModelTest.test(ModelTest.java:49)
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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
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: org.hibernate.PropertyValueException: not-null property references a null or transient value: dk.hibernatetest.model.C.b
at org.hibernate.engine.Nullability.checkNullability(Nullability.java:95)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:313)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:454)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:288)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:636)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:628)
at org.hibernate.engine.EJB3CascadingAction$1.cascade(EJB3CascadingAction.java:28)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
at org.hibernate.event.def.AbstractSaveEventListener.cascadeAfterSave(AbstractSaveEventListener.java:479)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:357)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:144)
at org.hibernate.ejb.event.EJB3PersistEventListener.saveWithGeneratedId(EJB3PersistEventListener.java:49)
at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:154)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:110)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:645)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:619)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:623)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:220)
... 21 more
As noted in TestModel.java, if some of the other entities (namely c, g or h) are passed to persist(), then the problem doesn't occur.
I've tried to debug the problem and the only difference I've seen inside ForeignKeys.Nullifier.nullifyTransientReferences() is that, in the cases where an exception is thrown, then the B instance that C.b points to has the state SAVING, whereas when the exception isn't thrown, then it has state MANAGED.
When the B instance has state SAVING, then ForeignKeys.Nullifier.nullifyTransientReferences() nulls then entry in it's value array.
After that, Nullability.checkNullability(), performs a null check, which fails because ForeignKeys.Nullifier.nullifyTransientReferences() just nulled the property in the values array.
Could it be a solution to reverse the order of the ForeignKeys.Nullifier.nullifyTransientReferences() and Nullability.checkNullability() (See AbstractEventListener.performSaveOrReplicate(...))
or does ForeignKeys.Nullifier.nullifyTransientReferences() instead have to take nullability into considerations?
/Jeppe
--
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-3910) Add support for custom dirty checking during flush
by Ovidio Mallo (JIRA)
Add support for custom dirty checking during flush
--------------------------------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Currently, Hibernate supports a special dirty checking on instrumented entities
in order to improve the flush performance. IMO, this optimization can often be
rather significant. However, the drawback is that you have to use bytecode
instrumentation in order to take advantage of this performance improvement which
might not be an option in some projects.
Therefore, I wanted to propose to extend the current dirty checking during flush
in such a way that the dirtyness information can also be directly provided by
clients. Thereby, I could think of two possible approaches to do this:
1. Introduce an interface which client entities might implement in case they
have some notion of dirtyness. The interface could look something like:
public interface DirtyAwareEntity {
boolean getMightBeDirty();
void setMightBeDirty(boolean mightBeDirty);
}
Using such an interface, Hibernate could easily check whether an entity might
be dirty during flush and it could also reset the dirty flag after flush just
as is currently done for instrumented classes. So this approach would probably
be rather easy to implement and very convenient for clients since they would
only have to implement that interface on the appropriate entities and set the
dirty flag when the entity is actually modified.
2. Add some hooks on event listeners and/or on the Interceptor for querying whether
an entity is dirty and for resetting the dirty flag. E.g. one could add the
following hook method to the DefaultFlushEntityEventListener class:
protected boolean requiresDirtyCheck(FlushEntityEvent event);
By default, this method would call EntityEntry#requiresDirtyCheck(Object entity)
as is done right now.
Resetting the dirty flag could maybe be done in Interceptor#postFlush() or some
dedicated method could be provided.
BTW, I know that currently there already is the Interceptor#findDirty() method which
already allows for some custom dirty checking but the problem from a performance
point of view is that this method requires the entity's property values as parameter
which are retrieved in DefaultFlushEntityEventListener#getValues() which is the most
expensive method during flush. This drawback of the findDirty() method has often been
noticed in comments on the news groups.
I personally think it would be nice if something could be done to improve the
performance of flushing in Hibernate since from what I read on the news groups and
the like, flushing still seems to often lead to performance problems in practice,
especially in larger projects where it is often not easy to avoid flushes or to
keep the numer of entities in the session cache small. In fact, we are having quite
some trouble with that in our project and having some custom dirty checking like the
one I'm proposing here would greatly help in our project and in other projects as
well, I guess.
--
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-3853) one-to-one mapping doesn support Primary Key Association
by Amar Singh (JIRA)
one-to-one mapping doesn support Primary Key Association
--------------------------------------------------------
Key: HHH-3853
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3853
Project: Hibernate Core
Issue Type: Bug
Components: envers
Environment: Hibernate - core 3.4.0-SNAPSHOT, Hibernate - envers (trunk build from today)
Reporter: Amar Singh
Attachments: one-to-one-pk.zip
one-to-one mapping with primary key association doesn't seem to be working. Eg.
Code:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="org.hibernate.envers.test.integration.onetoone.bidirectional" default-lazy="false">
<class name="BidirectionalRefIngPK" table="BIDIRECTIONAL_REFERENCING_ENTITY">
<id name="id" type="long" column="BIDIRECTIONAL_REFERENCING_ID" >
<generator class="foreign">
<param name="property">reference</param>
</generator>
</id>
<property name="data"/>
<property column="BIDIRECTIONAL_REFERENCING_ID" generated="never" insert="false" lazy="false" name="id" type="long" update="false"/>
<one-to-one name="reference" cascade="save-update" class="BidirectionalRefEdPK" constrained="true" />
</class>
<class name="BidirectionalRefEdPK" table="BIDIRECTIONAL_REFERENCED_ENTITY">
<id name="longId" type="long" column="BIDIRECTIONAL_REFERENCED_ID">
<generator class="native"/>
</id>
<property name="data"/>
<one-to-one name="referencing" cascade="all" class="BidirectionalRefIngPK" />
</class>
</hibernate-mapping>
When we try to load a BidirectionalRefIngPK, the underlying query invokes RelatedAuditExpression and since its not a foreign-key based one-to-one association the loading fails in method addToQuery of RelatedAuditExpression at line 52 (relatedEntity==null) with the following exception:
Code:
"This criterion can only be used on a property that is a relation to another property."
TO REPRODUCE
~~~~~~~~~~~~~
Please find a zip file attached which has four files:
- BidirectionalPrimaryAssociation.java (actual testng test case)
- BidirectionalRefEdPK.java (Entity 1)
- BidirectionalRefIngPK.java (Entity 2)
- mappings.hbm.xml
Please put the three java files in its package (org.hibernate.envers.test.integration.onetoone.bidirectional) and the mapping file in src/test/resources.
Now when you run envers tests you should see the failure.
Thanks for this great component !
--
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-3414) fetch profiles
by Steve Ebersole (JIRA)
fetch profiles
--------------
Key: HHH-3414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414
Project: Hibernate3
Issue Type: New Feature
Components: core, metamodel
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.4
The concept of fetch profiles as we are discussing here is basically to allow users to dynamically affect the mapped fetching strategy for associations at runtime.
Consider the following example:
<class name="Person">
...
<set name="addresses" lazy="true" fetch="subselect" ...>
...
</set>
</class>
<class name="Address">
...
</class>
This follows the normal recommendation to map associations as lazy and use a dynamic fetching strategy (ala HQL/Criteria) to modify this lazy behavior at runtime.
The fetaure discussed here would allow the same behavior for loading as well:
<hibernate-mapping>
<fetch-profile name="person-details">
<fetch path="Person.addresses" style="join"/>
</fetch-profile>
</hibernate-mapping>
Or:
<hibernate-mapping>
<class name="Person">
...
<fetch-profile name="person-details">
<fetch path="addresses" style="join"/>
</fetch-profile>
<set name="addresses" lazy="true" fetch="subselect" ...>
...
</set>
</class>
</hibernate-mapping>
Now, doing:
session.enableFetchProfile( "person-details" ).get( Person.class, 1 )...
will load Person#1 as well as their addresses in a single joined query.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[Hibernate-JIRA] Created: (ANN-721) ManyToOne Persisting Cascade in Embeddable
by Endre Jeges (JIRA)
ManyToOne Persisting Cascade in Embeddable
------------------------------------------
Key: ANN-721
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-721
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.1.GA
Environment: Java version:
java version "1.6.0_04"
Java(TM) SE Runtime Environment (build 1.6.0_04-b12)
Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing)
Oracle Version:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
PL/SQL Release 9.2.0.8.0 - Production
"CORE 9.2.0.8.0 Production"
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
hibernate: 3.2.6.ga
hibernate-annotations: 3.3.1.ga
hibernate-commons-annotations: 3.3.0.ga
hibernate-entitymanager: 3.3.1.ga
Reporter: Endre Jeges
Attachments: pairTest.zip
Hello,
I have found something that is a bit strange. For @ManyToOne association properties in an @Embeddable class the cascade PERSIST, SAVE-UPDATE option is not working well (not sure for the other cascade types), if the entities associated with ManyToOne are transient. I have created a unit test to check it and I have it attached to this issue. It is a maven2 project, and needs Oracle to run it. If I save the associated entites, then everything works fine, also the data structure is created well.
I have checked the forums and found similar problems, maybe they can help more then my post:
http://forum.hibernate.org/viewtopic.php?t=965238
http://forum.hibernate.org/viewtopic.php?t=976534
http://forum.hibernate.org/viewtopic.php?t=978112
http://forum.hibernate.org/viewtopic.php?t=978138
http://forum.hibernate.org/viewtopic.php?t=983766
http://forum.hibernate.org/viewtopic.php?t=983780
http://forum.hibernate.org/viewtopic.php?t=983868
Details:
@Entity
class CodedPairHolder {
@Id
private Long id;
@Column(name = "CODE", nullable = false, unique = true, updatable = false, length = 256)
private String code;
@CollectionOfElements
@JoinTable(name = "CODED_PAIR_HOLDER_PAIR_SET", joinColumns = @JoinColumn(name = "CODED_PAIR_HOLDER_ID"))
private final Set<PersonPair> pairs = new HashSet<PersonPair>(0);
........ constructors getters equals hashCode
}
@Embeddable
class PersonPair {
@ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH })
@Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH,
org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT })
@JoinColumn(name = "LEFT_PERSON_ID", nullable = false, updatable = false)
private Person left;
@ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH })
@Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH,
org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT })
@JoinColumn(name = "RIGHT_PERSON_ID", nullable = false, updatable = false)
private Person right;
........ constructors getters equals hashCode
}
@Entity
class Person {
@Id
private Long id;
@Column(name = "NAME", nullable = false, unique = true, updatable = false, length = 256)
private String name;
........ constructors getters equals hashCode
}
The error message is:
org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: Person
Regards,
jeges
--
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-2738) Eager fetch support for StatelessSession
by Christian Bauer (JIRA)
Eager fetch support for StatelessSession
----------------------------------------
Key: HHH-2738
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2738
Project: Hibernate3
Issue Type: Task
Components: core
Reporter: Christian Bauer
class Node {
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "PARENT_NODE_ID", nullable = true)
protected Node parent;
}
StatelessSession ss = getStatelessSession();
Node node = (Node) ss.get(Node.class, nodeId);
[testng] org.hibernate.AssertionFailure: possible non-threadsafe access to the session
[testng] at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:100)
[testng] at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
[testng] at org.hibernate.loader.Loader.doQuery(Loader.java:729)
[testng] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
[testng] at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
[testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
[testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
[testng] at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3042)
[testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:158)
[testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:153)
[testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:145)
--
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-3967) Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!
by Guenther Demetz (JIRA)
Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!
----------------------------------------------------------------------------
Key: HHH-3967
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3967
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Environment: 3.3.1 GA , SQLServer
Reporter: Guenther Demetz
Sometimes large stateful transactions are unavoidable and especially when having several large persistent collections in dirty state,
flushing becomes gradually more cpu intensive and slowly.
Analizing several stacktraces I detected that the thread most time is executing at the same point in reflection ,
see here a typical stacktrace:
java.lang.Class.isAssignableFrom(Native Method)
sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:36)
...
java.lang.reflect.Field.get(Field.java:358)
DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:55)
PojoEntityTuplizer(AbstractEntityTuplizer).getPropertyValue(Object, int) line: 300
SingleTableEntityPersister(AbstractEntityPersister).getPropertyValue(Object, int, EntityMode) line: 3609
Cascade.cascade(EntityPersister, Object, Object) line: 172
...
Making further investigations, I saw that:
- CascadingAction.PERSIST_ON_FLUSH requires NoCascadeChecking
- for all kind of properties the noCascade implementation is called
- regarding noCascade implementation checks only properties of type Entity !
public static final CascadingAction PERSIST_ON_FLUSH = new CascadingAction() {
...
public void noCascade(EventSource session, Object child, Object parent, EntityPersister persister, int propertyIndex) {
...
Type type = persister.getPropertyTypes()[propertyIndex];
if ( type.isEntityType() ) {
... check and throw eventually a TransientObjectException
}
}
Thus most property values are retrieved by reflection in vain as they are not of type entity.
With following code addition in org.hibernate.engine.Cascade.java
I was able do avoid most reflection method calls without affecting the behaviour:
org.hibernate.engine.Cascade.java
...
public void cascade(final EntityPersister persister, final Object parent, final Object anything) throws HibernateException {
...
else if ( action.requiresNoCascadeChecking() ) {
// Line:162
// begin Improvement
if (action == CascadingAction.PERSIST_ON_FLUSH) {
Type type = persister.getPropertyTypes()[i];
if ( !type.isEntityType() ) {
// Remark: goes only well as long PERSIST_ON_FLUSH noCascade implementation checks only entities
continue;
}
}
// end Improvement
action.noCascade(
eventSource,
persister.getPropertyValue( parent, i, entityMode ),
parent,
persister,
i
);
...
best regards
Guenther D.
--
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