November 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3230) getEntityName() throws org.hibernate.TransientObjectException: proxy was not associated with the session

by Howard M. Lewis Ship (JIRA)

getEntityName() throws org.hibernate.TransientObjectException: proxy was not associated with the session -------------------------------------------------------------------------------------------------------- Key: HHH-3230 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3230 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.2 Environment: Mac OS X, JDK 1.5 Reporter: Howard M. Lewis Ship I'm retrieving an entity that contains a OneToMany relationship. The master entity is retrieved, within a transaction, via Session.get(Class,Serializable). @Entity public class MapUnitSurvey extends ActiveDO { @ManyToOne(fetch = FetchType.LAZY) private VegetationType vegetationType; } @Entity public class VegetationType extends AbstractEnum { } ActiveDO and AbstractEnum are abstract base classes with @MappedSuperclass. I retrieve the vegationType: VegetationType type = survey.getVegetationType(); Then I need the type's entity name String entityName = session.getEntityName(type); This fails with the TransientObjectException. Inspecting with the debugger, I see that type is a CGLIB-enhanced proxy, and that there's a fully initialized bean in the target field of the proxy. I'll attach a screenshot of some debugging data. In summary; the entity was retrieved via a lazy fetch, appears the be correct, seems to be in the session and yet the exception occurs. I've tried to resolve this by re-fetching the object from the session, and a few other tries, with no luck. -- 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

15 years, 2 months

4
10
0 / 0

[Hibernate-JIRA] Created: (HHH-3332) Hibernate duplicate then child entity's on merge

by Rodrigo de Assumpção (JIRA)

Hibernate duplicate then child entity's on merge ------------------------------------------------ Key: HHH-3332 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3332 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6 Environment: JDK 1.6 Oracle 9i Hibernate 3.2.6 Hibernate Annotations 3.3.1 Hibernate EntityManager 3.3.2 Standalone Running Reporter: Rodrigo de Assumpção Priority: Critical The method merge from EntityManager causes a duplication of child entity's. class Father: @OneToMany(mappedBy = "father", cascade={CascadeType.ALL}, fetch=FetchType.LAZY) private List<Child> childList; class Child: @ManyToOne @JoinColumn(name = "ID_FATHER") private Father father; class BugTest EntityManagerFactory emf = Persistence.createEntityManagerFactory("JpaTestHB"); EntityManager em = emf.createEntityManager(); Father f = (Father) em.createQuery("SELECT f FROM Father f WHERE f.id = 1").getSingleResult(); Child c = new Child(); c.setFather(f); f.getChildList().add(c); em.getTransaction().begin(); em.merge(f); em.getTransaction().commit(); The execution of BugTest Class causes tow insert's on table "child". If you change the fetch mode to EAGER (into Father class) the problem not occurs. I make the same test with Toplink, and it make a unique insert, normal. -- 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

15 years, 2 months

13
29
0 / 0

[Hibernate-JIRA] Created: (HV-272) jaxb dependencies should be dependencies with scope 'provided' instead of profile dependencies

by Hardy Ferentschik (JIRA)

jaxb dependencies should be dependencies with scope 'provided' instead of profile dependencies ---------------------------------------------------------------------------------------------- Key: HV-272 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-272 Project: Hibernate Validator Issue Type: Bug Components: build Affects Versions: 4.0.2.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Fix For: 4.1.0 -- 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

15 years, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3608) DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB

by Matthias Gommeringer (JIRA)

DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB ----------------------------------------------------------------------------------------------------------------- Key: HHH-3608 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3608 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.2.6 Environment: Hibernate 3.2.6, Oracle (any version) Reporter: Matthias Gommeringer Priority: Blocker Attachments: PooledOptimizerTest.java We have several Application Servers (=JVMs) running each of them using Hibernate-Objects with the SequenceStyleGenerator+pooled configured. In unpredictable time intervals it happens that hibernate assigns the same ID to two completely different objects which results in a UniqueConstraintViolation exception from the database. Here an example with a description where hibernate fails: DB-Sequence setup: start=0 increment=2 PooledOptimizer.generate() with 2 threads (first assignment of hiValue/value): JVM-1 JVM-2 value=0=callback.nextval value=2=callback.nextval hiValue=4=callback.nextval hiValue=6=callback.nextval The problem's cause is in the PooledOptimizer.generate: when it initializes the value+hiValue for the first time it invokes callback.nextValue() twice which may provide values that do not belong to each other. The reason is that between the assignment of "value" and "hiValue" another JVM can retrieve a DB sequence value from the callback which leads to an inconsistent "value" and "hiValue" relation (see example above). A fix that works for multiple JVMs would be to invoke the "callback.getNextValue()" maximum once per "optimizer.generate()" call: public synchronized Serializable generate(AccessCallback callback) { if ( hiValue < 0 ) { value = callback.getNextValue(); hiValue = value + incrementSize; } else if ( value >= hiValue ) { value = callback.getNextValue(); hiValue = value + incrementSize; } return make(value++); } I attached a testcase that prooves the described problem (you can see that the IDs "2" and "3" are assigned two times). I would be very thankful if this problem could be fixed very soon since it is a showstopper which occurs very unpredictably. -- 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

15 years, 3 months

15
40
0 / 0

[Hibernate-JIRA] Created: (HHH-3551) Boolean substitution in informix

by Rouvignac (JIRA)

Boolean substitution in informix -------------------------------- Key: HHH-3551 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3551 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.3.1 Environment: Hibernate 3.2 Informix 9.40 Reporter: Rouvignac HQL Query : select order from Order order where order.printed = ? Parameter : true, false, Boolean.TRUE or Boolean.FALSE When the request is executed we get the following error : SQLSTATE: IX000 SQL CODE: -674 674: Routine (equal) can not be resolved. If as parameter we use "t" ot "f" everything works fine but it will not work with other DB. As a workaround we can use : property name="hibernate.query.substitutions">true t, false f</property> I investigated in Dialects : Dialect.java public String toBooleanValueString(boolean bool) { return bool ? "1" : "0"; } PostgreSQLDialect.java public String toBooleanValueString(boolean bool) { return bool ? "true" : "false"; } InformixDialect.java uses Dialect.java toBooleanValueString method. In my mind toBooleanValueString should be added to InformixDialect.java as follow : public String toBooleanValueString(boolean bool) { return bool ? "t" : "f"; } -- 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

15 years, 3 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3984) onPrepareStatement is called twice.

by Tobias Bergman (JIRA)

onPrepareStatement is called twice. ----------------------------------- Key: HHH-3984 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3984 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5 Environment: Windows, MySQL 5, Java 1.6 Reporter: Tobias Bergman onPrepareStatement is called twice when batched. First getSQL(sql) (which will call the interceptor) is called from prepareBatchStatement. After the invokation the prepareBatchStatement() will call prepareStatement(sql) which will also call getSQL(). -- 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

15 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4511) Problems with polymorphic queries with SINGLE_TABLE inheritance strategy

by Karoly Gacsal (JIRA)

Problems with polymorphic queries with SINGLE_TABLE inheritance strategy ------------------------------------------------------------------------ Key: HHH-4511 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4511 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.0.Beta-1 Environment: envers 1.2.1 Hibernate 3.3.2 Reporter: Karoly Gacsal Attachments: ChildAuditing.java Inheritance strategy is SINGLE_TABLE (discriminator). When I query for ParentType I do not get ChildType instances in the result, but ParentType instances. I checked the problem against envers 1.2.1/Hibernate 3.3.2 and against Hibernate 3.5.0.Beta-1 too. The testcase "\src\test\java\org\hibernate\envers\test\integration\inheritance\single\ChildAuditing.java" passes, but when I change the two sides of the equals method in testPolymorphicQuery()'s second assert the testcase fails, because the expected result is a ChildEntity, but in the result we get an instance of ParentEntity. Attached you can find the testcases changed by me. -- 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

15 years, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3524) setFetchMode ignored if using createCriteria

by Peter Weemeeuw (JIRA)

setFetchMode ignored if using createCriteria -------------------------------------------- Key: HHH-3524 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3524 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 8 Reporter: Peter Weemeeuw Hi, It seems that criteria.setFetchMode gets ignored if you combine it with createCriteria to add a restriction. This works as expected: DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class); c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN); But in this case the join doesn't happen (and I get a LazyInstantiationException further on). DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class); c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN); c.createCriteria("menuItemSubscriptions").add( Restrictions.eq("location", "B") ); This does not happen if I set lazy="false" in the mappings file. Regards, Peter -- 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

15 years, 3 months

8
13
0 / 0

[Hibernate-JIRA] Created: (ANN-747) @CollectionOfElements does not cascade on delete

by Nicole Rauch (JIRA)

@CollectionOfElements does not cascade on delete ------------------------------------------------ Key: ANN-747 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-747 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Hibernate 3.2.6 GA Database: H2 1.0.72 Reporter: Nicole Rauch Consider the following constellation: @Embeddable public class Foo { // ... } @Entity public class Bar { @CollectionOfElements private Set<Foo> myFoos; // ... } When I persist a Bar object that contains some Foos, and when I later decide to delete the Bar object, I get a foreign key constraint violation error message because the Foo objects, which contain a reference to the Bar object that owns them, are not deleted automatically. I would expect the default behaviour to be "on delete cascade" because the Foo objects are embeddables, thus they cannot exist on their own without the Bar object that owns them. But there is no way to tell Hibernate to cascade: - the @OnDelete annotation is only allowed for OneToMany relations - the @Cascade annotation is being ignored - there is no "cascade" property for the CollectionOfElements So my question is: Why does the cascading not occur automatically, and how do I tell Hibernate to cascade anyways? Thanks a lot in advance, Nicole -- 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

15 years, 3 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3273) One-to-Many relationship not working with custom Loader

by Darren Hicks (JIRA)

One-to-Many relationship not working with custom Loader -------------------------------------------------------- Key: HHH-3273 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3273 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1 Environment: hibernate-3.2.6.jar Reporter: Darren Hicks Within the context of a One-to-Many relationship, NamedQueryCollectionInitializer .initialize() never actually populates the PersistantBag on the parent after it calls query.setCollectionKey( key ).setFlushMode( FlushMode.MANUAL ).list() to retrieve the children. This is documented in the forums here: http://forums.hibernate.org/viewtopic.php?t=986428 Additionally, the poster has a fix posted which may solve the problem, or at least lay out the groundwork for a solution. Here is the proposed implementation of NamedQueryCollectionInitializer.initialize(): public void initialize(Serializable key, SessionImplementor session) throws HibernateException { if (log.isDebugEnabled()) { log.debug("initializing collection: " + persister.getRole() + " using named query: " + queryName); } // TODO: is there a more elegant way than downcasting? AbstractQueryImpl query = (AbstractQueryImpl) session .getNamedSQLQuery(queryName); if (query.getNamedParameters().length > 0) { query.setParameter(query.getNamedParameters()[0], key, persister .getKeyType()); } else { query.setParameter(0, key, persister.getKeyType()); } List list = query.setCollectionKey(key).setFlushMode(FlushMode.MANUAL) .list(); // Uh, how 'bout we save the collection for later retrieval? CollectionKey collectionKey = new CollectionKey(persister, key, session .getEntityMode()); for (Object object : session.getPersistenceContext() .getCollectionsByKey().keySet()) { if (collectionKey.equals(object)) { PersistentCollection persistentCollection = session .getPersistenceContext().getCollection(collectionKey); Serializable[] serializables = new Serializable[list.size()]; for (int i = 0; i < list.size(); i++) { serializables[i] = persister.getElementType().disassemble( list.get(i), session, persistentCollection.getOwner()); } persistentCollection.initializeFromCache(persister, serializables, persistentCollection.getOwner()); persistentCollection.setSnapshot(key, persistentCollection .getRole(), serializables); persistentCollection.afterInitialize(); session.getPersistenceContext().getCollectionEntry( persistentCollection).postInitialize( persistentCollection); } } } -- 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

15 years, 3 months

6
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2009