[Hibernate-JIRA] Created: (HHH-3007) Unchanged persistent set gets marked dirty on session.merge()
by Lars Koedderitzsch (JIRA)
Unchanged persistent set gets marked dirty on session.merge()
-------------------------------------------------------------
Key: HHH-3007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Reporter: Lars Koedderitzsch
Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection.
This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush.
I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace().
Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line:
Object result = target == null || target == original ? instantiateResult( original ) : target;
The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet).
In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet.
This way the PersistentSet remains marked dirty.
A workaround is to manually clear the dirty state of an immutable collection after merge but before flush.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-3527) Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl
by Paul FitzPatrick (JIRA)
Null Version Comparator for versioned class due to reuse of Second Level CacheDataDescriptionImpl
-------------------------------------------------------------------------------------------------
Key: HHH-3527
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3527
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.1
Environment: 3.3.1 GA, Postgres 8.3.3, EH Cache
Reporter: Paul FitzPatrick
Priority: Minor
When the SessionFactoryImpl constructor builds the EntityPersister for classes, it consults a cache of entityAccessStrategies for all the known second level cache regions. If only some of the classes in that region have version tags, then it is possible the cached EntityRegionAccessStrategy will be created without a Version Comparator. Subsequent calls to load an object using a Criteria query failed with a NullPointerException (stack trace below). The line being executed is "return version!=null && comparator.compare(version, newVersion) < 0;" and in this case "version" is an Integer object and comparator is null.
Not sure the appropriate solution. It would seem from an examination of the code that if the EntityRegionAccessStrategy is to be shared, then all classes in the second level cache region _must_ either all have a "version" column or all have no "version" column. Further, it seems implied that if they use a "version" column, then they must all use the exact same data type. If this is the case, then a better error check on the configuration data may be in order.
Caused by: java.lang.NullPointerException
at org.hibernate.cache.ReadWriteCache$Item.isPuttable(ReadWriteCache.java:426)
at org.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:180)
at org.hibernate.cache.impl.bridge.EntityAccessStrategyAdapter.putFromLoad(EntityAccessStrategyAdapter.java:68)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:179)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877)
at org.hibernate.loader.Loader.doQuery(Loader.java:752)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2228)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
at org.hibernate.loader.Loader.list(Loader.java:2120)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)
at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:328)
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2097) LAZY property results in org.hibernate.TransientObjectException after merge
by Reto Urfer (JIRA)
LAZY property results in org.hibernate.TransientObjectException after merge
---------------------------------------------------------------------------
Key: HHH-2097
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2097
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: Hibernate3.2 cr4 with Annotations cr2 and EntityManager cr2, Oracle10g R2, WindowsXP
Reporter: Reto Urfer
Priority: Critical
Attachments: BugLazyPropertyMerge.zip
Entity1 has a property e2 which references Entity2. This property is defined as follows.
@ManyToOne(fetch = FetchType.LAZY, optional = false)
private Entity2 e2;
If you have an instance e1 of Entity1 which has not initialized property e2 and you merge e1 to the EntityManager within a transaction, then you get the following exception during commit:
Exception in thread "main" javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:63)
at com.test.Test.main(Test.java:42)
Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.test.Entity1.e2 -> com.test.Entity2
at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:350)
at org.hibernate.engine.Cascade.cascade(Cascade.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:130)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:53)
... 1 more
I added a small Testproject to reproduce this bug.
--
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, 4 months
[Hibernate-JIRA] Created: (HBX-1042) Make DocHelper robust against failing buildSettings()
by Arnout Engelen (JIRA)
Make DocHelper robust against failing buildSettings()
-----------------------------------------------------
Key: HBX-1042
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1042
Project: Hibernate Tools
Issue Type: Improvement
Components: hbm2doc
Reporter: Arnout Engelen
Attachments: dochelper.diff.txt
DocHelper calls cfg.buildSettings(). to get the Dialect, default catalog name and default schema name.
However, cfg.buildSettings() may fail with a HibernateException (example below).
It would be nice to have DocHelper handle this more gracefully. Attached is a simple patch that does this.
(background: I'd like to use the Configuration I'm getting from a Spring LocalSessionFactoryBean, which after initial creation leaves its LocalDataSourceConnectionProvider in a state that yiels a HibernateException when calling 'configure()' on it, which buildSettings() does. Because of this issue, I cannot use the DocExporter for my Spring-based hibernate configurations)
--
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, 4 months