-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]


Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 4 posts ] 
  Previous topic | Next topic 
Author Message
rabagley
 Post subject: No persister for java.lang.Long
PostPosted: Thu Sep 04, 2003 5:04 pm 
Newbie

Joined: Thu Sep 04, 2003 4:47 pm
Posts: 5
When a type (that I can't identify from the error messages) attempts to cascade a relation to another type (that I can't identify until I modify the error messages), I get a message which indicates that Hibernate can't figure out how to resolve a java.lang.Long into an identifier.

Here is the original stack trace and the modified stack trace. In both cases, you can safely ignore the com.accruent exception (it's included for calling context).

Code:
     [java] Caused by: com.accruent.orm.PersistenceException: exception caught while preparing hibernate transaction (flush any cached changes to db).
     [java]     at com.accruent.orm.impl.HibernateTransactionWrapper.doPrepare(HibernateTransactionWrapper.java:191)
     [java]     at com.accruent.txn.impl.TransactionAC.prepare(TransactionAC.java:108)
     [java]     ... 34 more
     [java] Caused by: net.sf.hibernate.MappingException: No persister for: java.lang.Long
     [java]     at net.sf.hibernate.impl.SessionFactoryImpl.getPersister(SessionFactoryImpl.java:420)
     [java]     at net.sf.hibernate.impl.SessionImpl.getPersister(SessionImpl.java:2302)
     [java]     at net.sf.hibernate.impl.SessionImpl.getPersister(SessionImpl.java:2309)
     [java]     at net.sf.hibernate.impl.SessionImpl.getEntityIdentifierIfNotUnsaved(SessionImpl.java:2374)
     [java]     at net.sf.hibernate.type.EntityType.getIdentifier(EntityType.java:56)
     [java]     at net.sf.hibernate.type.EntityType.isDirty(EntityType.java:124)
     [java]     at net.sf.hibernate.type.TypeFactory.findDirty(TypeFactory.java:210)
     [java]     at net.sf.hibernate.persister.AbstractEntityPersister.findDirty(AbstractEntityPersister.java:209)
     [java]     at net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2182)
     [java]     at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2017)
     [java]     at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2004)
     [java]     at com.accruent.orm.impl.HibernateTransactionWrapper.doPrepare(HibernateTransactionWrapper.java:185)
     [java]     ... 35 more


Since this exception is pretty useless, I inserted a more informative exception in the EntityType class to produce this stack trace:

Code:
     [java] Caused by: com.accruent.orm.PersistenceException: exception caught while preparing hibernate transaction (flush any cached changes to db).
     [java]     at com.accruent.orm.impl.HibernateTransactionWrapper.doPrepare(HibernateTransactionWrapper.java:191)
     [java]     at com.accruent.txn.impl.TransactionAC.prepare(TransactionAC.java:108)
     [java]     ... 36 more
     [java] Caused by: net.sf.hibernate.HibernateException: in type 'com.accruent.base.impl.AbstractResource', an attempt to resolve the identifier '3835' failed with exception.: No persister for: java.lang.Long
     [java]     at net.sf.hibernate.type.EntityType.getIdentifier(EntityType.java:60)
     [java]     at net.sf.hibernate.type.EntityType.isDirty(EntityType.java:130)
     [java]     at net.sf.hibernate.type.TypeFactory.findDirty(TypeFactory.java:210)
     [java]     at net.sf.hibernate.persister.AbstractEntityPersister.findDirty(AbstractEntityPersister.java:209)
     [java]     at net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2182)
     [java]     at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2017)
     [java]     at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2004)
     [java]     at com.accruent.orm.impl.HibernateTransactionWrapper.doPrepare(HibernateTransactionWrapper.java:185)
     [java]     ... 37 more
     [java] Caused by: net.sf.hibernate.MappingException: No persister for: java.lang.Long
     [java]     at net.sf.hibernate.impl.SessionFactoryImpl.getPersister(SessionFactoryImpl.java:420)
     [java]     at net.sf.hibernate.impl.SessionImpl.getPersister(SessionImpl.java:2302)
     [java]     at net.sf.hibernate.impl.SessionImpl.getPersister(SessionImpl.java:2309)
     [java]     at net.sf.hibernate.impl.SessionImpl.getEntityIdentifierIfNotUnsaved(SessionImpl.java:2374)
     [java]     at net.sf.hibernate.type.EntityType.getIdentifier(EntityType.java:57)
     [java]     ... 44 more


The only other clue that I have is that some types were incorrectly using property tags instead of a many-to-one tags. I tried to eliminate all of the errant references and change them to many-to-one. I don't know if this issue is related to that problem or something else.

Any hints as to what might be going on here? Why can't AbstractResource convert a java.lang.Long into it's identifier here (even though that type passes many other unit tests, including full CRUD tests)?

I don't think it will do much good (since I think the problem is in one of the two dozen types that refers to resource), but here's the mapping file for AbstractResource:

Code:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>

  <!-- Commitment mapping definition -->
  <class name="com.accruent.base.impl.AbstractResource"
         table="ORI_RESOURCE"
         mutable="true"
         polymorphism="implicit">

    <id name="objectId" column="RESOURCE_OID" type="long">
      <generator class="native">
        <param name="sequence">next_oid</param>
      </generator>
    </id>

    <many-to-one name="parent" column="PARENT_FK"
        class="com.accruent.base.impl.AbstractResource"/>

    <set name="fragmentSet" table="ORI_RESOURCE">
        <key column="PARENT_FK"/>
        <one-to-many class="com.accruent.base.impl.AbstractResource"/>
    </set>

    <set name="contractSet" table="CONTRACT_RESOURCE_MM">
        <key column="RESOURCE_FK"/>
        <many-to-many column="CONTRACT_FK"
            class="com.accruent.base.impl.Contract"/>
    </set>

    <set name="controllerSet" table="RESOURCE_CONTROLLER_MM">
        <key column="RESOURCE_FK"/>
        <many-to-many column="AGENT_FK"
            class="com.accruent.base.impl.AbstractAgent"/>
    </set>

    <set name="commitmentSet" table="ATOMIC_CMTMT">
        <key column="RESOURCE_FK"/>
        <one-to-many class="com.accruent.base.impl.AtomicCommitment"/>
    </set>

    <set name="eventSet" table="EVENT">
        <key column="RESOURCE_FK"/>
        <one-to-many class="com.accruent.base.impl.Event"/>
    </set>

    <joined-subclass name="com.accruent.finance.impl.Account"
        table="FIN_ACCOUNT">

        <key column="ACCOUNT_OID"/>

        <property name="accountNumber" column="ACCOUNT_NUMBER" type="string"/>

        <property name="routingNumber" column="ROUTING_NUMBER" type="string"/>

    </joined-subclass>

    <joined-subclass name="com.accruent.realestate.impl.LeasableSpace"
        table="RE_SPACE">

        <key column="SPACE_OID"/>

        <property name="name" column="SPACE_NAME" type="string"/>

        <many-to-one name="location" column="LOCATION_FK" cascade="save-update"
            class="com.accruent.realestate.impl.Location"/>

        <component name="area">
            <property name="amount" column="AREA" type="big_decimal"/>
        </component>

        <component name="rent">
            <property name="amount" column="RENT" type="big_decimal"/>
        </component>

    </joined-subclass>

  </class>

</hibernate-mapping>


Any hints? Has anyone seen anything like this before?

Regards,
Ross
Top
 Profile  
 
rabagley
 Post subject: Re: No persister for java.lang.Long
PostPosted: Thu Sep 04, 2003 6:19 pm 
Newbie

Joined: Thu Sep 04, 2003 4:47 pm
Posts: 5
This is apparently happening during a query only transaction at the close of the transaction. When the Session attempts to see if the Rent's Contract is dirty (I'll include the Rent's hbm.xml here), the Contract doesn't appear to know how to handle it's object id.

Rent is a joined subtype of AggregateCommitment which is a joined subtype of CommitmentAC (several types have been trimmed from this hbm.xml file).
Code:
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
  "-//Hibernate/Hibernate Mapping DTD 2.0//EN"
  "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping>

  <!-- Commitment mapping definition -->
  <class name="com.accruent.base.impl.CommitmentAC"
         table="COMMITMENT"
         mutable="true"
         polymorphism="implicit">

    <id name="objectId" column="COMMITMENT_OID" type="long">
      <generator class="native">
        <param name="sequence">next_oid</param>
      </generator>
    </id>

    <many-to-one name="contract" column="CONTRACT_FK" cascade="none"
        class="com.accruent.base.impl.Contract"/>

    <many-to-one name="reciprocal" column="RECIPROCAL_FK" cascade="none"
        class="com.accruent.base.impl.CommitmentAC"/>

    <property name="statusName" column="STATUS" type="string"/>

    <property name="name" column="COMMITMENT_NAME" type="string"/>

    <many-to-one name="activeDate" column="ACTIVE_DATE_FK"
        cascade="save-update"
        class="com.accruent.sched.impl.DateAC"/>

    <!-- AggregateCommitment definition -->
    <joined-subclass name="com.accruent.base.impl.AggregateCommitment"
        table="AGGREGATE_CMTMT">
        <key column="AGGREGATE_OID"/>

        <set name="childSet" table="AGGCMTMT_CHILD_MM" inverse="true" cascade="save-update">
            <key column="AGGREGATE_FK"/>
            <many-to-many column="CHILD_FK"
                class="com.accruent.base.impl.CommitmentAC"/>
        </set>

        <joined-subclass name="com.accruent.realestate.impl.Rent"
            table="RE_RENT">

            <key column="RENT_OID"/>

            <component name="amount">
                <property name="amount" column="AMOUNT" type="big_decimal"/>
            </component>

            <property name="termName" column="TERM_NAME" type="string"/>

            <property name="basedOn" column="BASED_ON" type="string"/>

        </joined-subclass>

    </joined-subclass>

  </class>

</hibernate-mapping>


These types of queries on these same types are working in other tests just fine. What could we be doing to cause Hibernate to forget how to interpret a java.lang.Long as an objectId? Also, why would everything in the transaction go perfectly fine until a commit when there are no changes to the persisted objects?

Regards,
Ross
Top
 Profile  
 
gavin
 Post subject:
PostPosted: Thu Sep 04, 2003 10:37 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
I bet you are doing something dodgy and explicitly outlawed like calling a query during execution of another query, or somehow other sparking a flush() in the middle of loading a result set.


This exception sometimes occurs when a flush() happens in the middle of query execution. There is object state that is in the "hydrated" state, where object ids have not yet been transformed into object references.


How about you show the entire stack trace (ie. before HibernateTransactionWrapper.doPrepare() is called).
Top
 Profile  
 
rabagley
 Post subject:
PostPosted: Fri Oct 17, 2003 7:03 pm 
Newbie

Joined: Thu Sep 04, 2003 4:47 pm
Posts: 5
Your supposition was correct. Someone else had a problem with Session.load(...) (still not sure what the problem was) and in the exception, thought that it would be a good idea to make an equivalent query and call Session.find(...) to "try it again".

This 1) hid the exception from the load(...) and then 2) instigated a flush at the beginning of the find(...) which caused the previously failed (and therefore partially loaded) object from the load to barf with an entirely different (and extraordinarily confusing) error.

The rest of the stack trace wouldn't have helped. It just looked like "normal" user-code since the real root of the problem was in discarding the exception from the load(...) and pretending that the load(...) had no effect on the transaction state.

Thanks for the help.

Regards,
Ross
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 1
  [ 4 posts ] 

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.