[Hibernate-JIRA] Created: (EJB-328) Missing flush before lock() when LockModeType is AUTO
by Per Olesen (JIRA)
Missing flush before lock() when LockModeType is AUTO
-----------------------------------------------------
Key: EJB-328
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-328
Project: Hibernate Entity Manager
Issue Type: Bug
Components: EntityManager
Affects Versions: 3.3.1.GA
Environment: core: 3.2.5.ga
entitymanager: 3.3.1.ga
annotations: 3.3.0.ga
Reporter: Per Olesen
Priority: Minor
When I try to WRITE lock() a newly persisted entity using entityManager.lock, I get a StaleObjectStateException, telling me that some other transaction updated or deleted the row. I am doing this in the same transaction (persist and lock).
By digging into the code, I see that the exception is thrown inside the SelectLockingStrategy.lock method, around these lines:
ResultSet rs = st.executeQuery();
try {
if ( !rs.next() ) {
if ( factory.getStatistics().isStatisticsEnabled() ) {
factory.getStatisticsImplementor()
.optimisticFailure( lockable.getEntityName() );
}
throw new StaleObjectStateException( lockable.getEntityName(), id );
}
}
The query executed here is the one which performs the select on id with FOR UPDATE. This select finds nothing, hence the exception.
Setting show_sql = true shows me, that no insert is performed. Debugging the flush mode tells me, that it is set to AUTO.
Shouldn't AUTO flush mode have the side effect, that a flush is performed before a query?
Performing an explicit flush, before the lock, makes everything green :-), so this is my current work-around.
Here is the exception (sanitized for company info):
org.springframework.orm.jpa.JpaOptimisticLockingFailureException: nested exception is javax.persistence.OptimisticLockException
Caused by: javax.persistence.OptimisticLockException
at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:643)
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:600)
at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:379)
...
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.foo.bar#32]
at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:78)
at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1334)
at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:88)
at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:64)
at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:584)
at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:576)
at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:376)
...
--
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
13 years, 11 months
[Hibernate-JIRA] Created: (HBX-1092) hbm2doc with graphing fails on MacOSX
by Avram Cherry (JIRA)
hbm2doc with graphing fails on MacOSX
-------------------------------------
Key: HBX-1092
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1092
Project: Hibernate Tools
Issue Type: Bug
Components: hbm2doc
Affects Versions: 3.2.0.GA, 3.2.2
Reporter: Avram Cherry
In the method org.hibernate.tool.hbm2x.DocExporter.dotToFile, the portions of the command passed to Runtime.exec() are being passed to an escape(String) method that optionally adds quotes to the executable file path and the path to the input file, but only if the OS is not linux. MacOSX is not linux, but adding quotes causes exec() to fail.
The solution is to change the following statement:
String exeCmd = escape(dotExeFileName) + " -T" + getFormatForFile(outFileName) + " " + escape(dotFileName) + " -o " + escape(outFileName);
to:
String[] exeCmd = new String[] {dotExeFileName, " -T", getFormatForFile(outFileName), dotFileName, " -o ", outFileName};
If you pass the command and arguments as separate strings within an array to Runtime.exec() you do not need to quote filenames, regardless of platform.
A (potentially very harmful) workaround is to pass -Dos.name=Linux to the VM.
Please note that I've checked both the 3.2 branch and trunk and both contain the same problem.
--
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
[Hibernate-JIRA] Created: (HHH-3824) OneToOne join by Non-primary key column throws PropertyAccessException when join column is String
by sathish (JIRA)
OneToOne join by Non-primary key column throws PropertyAccessException when join column is String
-------------------------------------------------------------------------------------------------
Key: HHH-3824
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3824
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria, query-hql
Affects Versions: 3.3.1
Environment: Microsoft SQL server 2005, Hibernate 3.3.1
Reporter: sathish
Attachments: trace.txt
When i try to join 2 entities by OneToOne using a Non-primary key column, it throws the following exception:
org.hibernate.PropertyAccessException: could not get a field value by reflection getter of com.xxx.domain.Inventory.sku
Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field com.inwk.estore.server.domain.Inventory.sku to java.lang.Integer
[Full stacktrace attached]
sku is the Non-primary key String join column by which im trying to do a OneToOne join between Item and Inventory entity.
Apparently its trying to interpret Sku as an Integer column. Adding columnDefinition as VARCHAR/String doesn't help either
Mappings for Item and Inventory are below:
class Item{
@Id
Long id;
@Column
String sku;
//some more properties
@OneToOne(optional = true)
@JoinColumn(name = "sku", referencedColumnName = "sku", insertable = false, updatable = false)
Inventory inventory;
}
class Inventory{
@Id
Long id
@Column
String sku
@Column
Long quantity;
}
--
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
[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
14 years
[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
14 years