[Hibernate-JIRA] Created: (HHH-2486) CacheException when using Hibernate with JBoss Cache's optimistic locking
by Rob Worsnop (JIRA)
CacheException when using Hibernate with JBoss Cache's optimistic locking
-------------------------------------------------------------------------
Key: HHH-2486
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2486
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2.
JBoss Cache 1.4.1.SP2
Affects all database platforms
Reporter: Rob Worsnop
Attachments: testcase.zip
See http://forum.hibernate.org/viewtopic.php?p=2343590
org.hibernate.action.BulkOperationCleanupAction evicts entities and then evicts entity collections.
So, with the attached test case, it does the following (in pseudo-code):
remove /com/medq/test/A
remove /com/medq/test/A/bs // throws exception
Obviously removing "/com/medq/test/A" also removes "/com/medq/test/A/bs", so the last line is superfluous (as well as causing an exception to be thrown).
Is there a reason why org.hibernate.cache.OptimisticTreeCache.clear doesn't call option.setFailSilently(true)? The exception would be swallowed by JBoss Cache if it did.
Here's the stack trace:
org.hibernate.cache.CacheException: org.jboss.cache.CacheException: Unable to find parent node with Fqn /com/medq/test/A
at org.hibernate.cache.OptimisticTreeCache.clear(OptimisticTreeCache.java:169)
at org.hibernate.cache.TransactionalCache.clear(TransactionalCache.java:124)
at org.hibernate.impl.SessionFactoryImpl.evictCollection(SessionFactoryImpl.java:874)
at org.hibernate.action.BulkOperationCleanupAction.evictCollectionRegions(BulkOperationCleanupAction.java:142)
at org.hibernate.action.BulkOperationCleanupAction.init(BulkOperationCleanupAction.java:103)
at org.hibernate.engine.query.NativeSQLQueryPlan.coordinateSharedCacheCleanup(NativeSQLQueryPlan.java:134)
at org.hibernate.engine.query.NativeSQLQueryPlan.performExecuteUpdate(NativeSQLQueryPlan.java:144)
at org.hibernate.impl.SessionImpl.executeNativeUpdate(SessionImpl.java:1163)
at org.hibernate.impl.SQLQueryImpl.executeUpdate(SQLQueryImpl.java:334)
at com.medq.test.TestHibernate.main(TestHibernate.java:39)
Caused by: org.jboss.cache.CacheException: Unable to find parent node with Fqn /com/medq/test/A
at org.jboss.cache.interceptors.OptimisticNodeInterceptor.removeNode(OptimisticNodeInterceptor.java:218)
at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:110)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:88)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:84)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:126)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5776)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3855)
at org.jboss.cache.TreeCache.remove(TreeCache.java:3438)
at org.hibernate.cache.OptimisticTreeCache.clear(OptimisticTreeCache.java:166)
... 9 more
As a workaround, the region name for the entity collection can be overridden so that it isn't underneath the entity in the tree.
In other words, something like "collections/com/medq/test/A/bs" instead of the default "com/medq/test/A/bs"
--
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
17 years, 6 months
[Hibernate-JIRA] Commented: (HHH-1961) Schema validation fails with floating point column in Oracle 10g
by richard yang (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961?page=c... ]
richard yang commented on HHH-1961:
-----------------------------------
I have the same issue with Oracle 10g. I cannot map a double or big_decimal type to oracle NUMBER wtih precision and scale. I tried many combination including using sql-type="DECIMAL(4,1)" and sql-type="NUMERIC(4,1)". No luck. Can the validator skip this check? I am dead in the water with our project. We might have to not use hibernate anymore.
We use java 1.6 and jboss 4.0.3sp1.
> Schema validation fails with floating point column in Oracle 10g
> ----------------------------------------------------------------
>
> Key: HHH-1961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1961
> Project: Hibernate3
> Issue Type: Bug
> Affects Versions: 3.2.0.cr2
> Environment: 3.2 CR 2, Oracle 10g express edition release 2, Windows XP service pack 2, JDK 1.5.0_06
> Reporter: Daniel Dyer
>
> I have a table (created automatically by Hibernate) for mapping a double field. The table creation from Ant works fine but when starting up JBoss with the hibernate.hbm2ddl.auto property set to validate, I get the following exception:
> Caused by: org.hibernate.HibernateException: Wrong column type: percentage, expected: double precision
> at org.hibernate.mapping.Table.validateColumns(Table.java:219)
> at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:965)
> at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
> at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:296)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1176)
> at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:414)
> at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:575)
> at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:245)
> at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:108)
> at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:260)
> ... 127 more
> Doing a "desc" on the table reveals that the column is of type FLOAT with a length of 22.
> I think this may be related to issue HHH-1566 or HHH-1008.
--
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
17 years, 6 months
[Hibernate-JIRA] Commented: (ANN-376) @SecondaryTable together with @Inheritance(strategy=InheritanceType.JOINED) fails
by Ilya Liubovich (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-376?page=co... ]
Ilya Liubovich commented on ANN-376:
------------------------------------
What this is it duplicate off? I have the same issue without annotations with 3.2.2
> @SecondaryTable together with @Inheritance(strategy=InheritanceType.JOINED) fails
> ---------------------------------------------------------------------------------
>
> Key: ANN-376
> URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-376
> Project: Hibernate Annotations
> Issue Type: Bug
> Affects Versions: 3.2.0.cr1
> Environment: Hibernate 3.2.0.cr2 included in JBoss4.0.4GA, MySQL 5
> Reporter: André J. Rogger
>
> Persister of JoinedSubclassEntity fails together with secondary table annotation (the other inheritence strategies are working fine).
> For example with the following two classes A and B:
> [A.java]
> @Entity
> @SecondaryTable(name="C")
> @Inheritance(strategy=InheritanceType.JOINED)
> public class A {
> @Id
> long id;
>
> @Column(table="C")
> String fieldInC;
> }
> [B.java]
> @Entity
> public class B extends A {
> String fieldOfB;
> }
> the deployment produces the following error:
> org.hibernate.AssertionFailure: Table C not found
> at org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId(JoinedSubclassEntityPersister.java:444)
> at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init>(JoinedSubclassEntityPersister.java:225)
> at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:58)
> ...
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HHH-2518) Inheritance Mapping with not distinct composite-key over all tables
by Rainer Buhl (JIRA)
Inheritance Mapping with not distinct composite-key over all tables
-------------------------------------------------------------------
Key: HHH-2518
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2518
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Environment: XP
Reporter: Rainer Buhl
table 1: conversionRuleMT
table 2: conversionRuleQCS
fields: client_id, subscriber_id, input_value, output_value
composite-key: client_id + subscriber_id + input_value
entries (two entries in different table with the same key: 1, 1, A):
conversionRuleMT
1, 1, A, MT1
2, 1, 3, MT3
conversionRuleQCS
1, 1, A, QCS1
3, 1, K, QCS4
abstract class: ConversionRule
concrete classes: ConversionRuleMT, ConversionRuleQCS
mapping
<class name="ConversionRule" abstract="true">
<composite-id>
<key-property name="clientId" column="client_id"></key-property>
<key-property name="subscriberId" column="subscriber_id"></key-property>
<key-property name="inputValue" type="string" column="input_value" />
</composite-id>
<property name="outputValue" type="string" column="output_value"/>
<property name="description" column="DESCRIPTION" />
<property name="isDefault" column="IS_DEFAULT" />
<union-subclass name="ConversionRuleMT" table="subscribing_client_MT"></union-subclass>
<union-subclass name="ConversionRuleQCS" table="SUBSCRIBING_CLIENT_QCS">
</unionsubclass>
</class>
from hibernate created objects contained in one collection:
- objects from type conversionRuleMT:
"1, 1, A, MT1"
"2, 1, 3, MT3"
"1, 1, A, QCS1" => Error,wrong class, because another table!,
but same key (1,1,A) as objec1 1 from class conversionRuleMT. Must be from type conversionRuleQCS!
- objects from type conversionRuleQCS
"3, 1, K, QCS4"
Hibernate does not distinguishe the different class of two entries from different tables which
have the same composite-id. The first object of table conversionRuleMT ("1, 1, A, MT1") in the collection
defines from which type is the next item from another table, because both entries have the same key.
The same key (1, 1, A) has higher priority than the different table from where the next
object comes "1, 1, A, QCS1" (conversionRuleQCS). And hibernate does create a new object nor it has the same "identity",
but from a wrong type.
Is this a bug, or a feature? Or is there a solution, e.g. a overwritten equals-method of ConversionRule like this
equals-method:
... this.getClass() + this.clientId + this.subscriberId + this.inputValue ...
--
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
17 years, 6 months
[Hibernate-JIRA] Updated: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
by Hontvári József (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=all ]
Hontvári József updated HHH-1569:
---------------------------------
Attachment: ImmutableNaturalId-hibernate3.2.2.patch
The problem is still present in 3.2.2. I attached Tom Dunstan's patch but in the unified diff format and added the missing comment which caused the whole problem (that was the only undocumented function in that class...).
I cannot follow the code, but it seems to me that quite a few lines deal with the problem that the usual loading functions don't load unmutable properties from the database. The same amount of code could be used instead to force loading of natural key values even if some of them are unmutable - they will be needed later when hibernate verifies that they were not changed accidentally.
> Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
> -------------------------------------------------------------------------
>
> Key: HHH-1569
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases
> Reporter: Tom Dunstan
> Priority: Minor
> Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip, ImmutableNaturalId-hibernate3.2.2.patch
>
>
> It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug. It added the following lines:
> if ( loaded == null ) {
> loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister );
> }
> Further down, loaded is used thusly:
> int prop = props[i];
> if ( !updateable[prop] ) {
> if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) {
> throw new HibernateException(
> Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays.
> I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable.
> Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used.
> (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2).
--
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
17 years, 6 months
[Hibernate-JIRA] Assigned: (HHH-1582) PostInsertListener + "post-commit-insert"
by Emmanuel Bernard (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582?page=all ]
Emmanuel Bernard reassigned HHH-1582:
-------------------------------------
Assign To: Emmanuel Bernard
> PostInsertListener + "post-commit-insert"
> -----------------------------------------
>
> Key: HHH-1582
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1582
> Project: Hibernate3
> Type: Bug
> Versions: 3.1.2
> Reporter: Daniel Gredler
> Assignee: Emmanuel Bernard
> Fix For: 3.3
>
> Original Estimate: 3 hours
> Remaining: 3 hours
>
> I'm using a custom PostInsertEventListener mapped to the "post-commit-insert" event to process domain objects. However, PostInsertEventListener's onPostInsert(PostInsertEvent) is getting called even when the insert was not successful (ie, due to a unique constraint in the database or some such). It looks to me like Hibernate should either a) not invoke the event listener if the insert failed or b) provide state (perhaps in the form of a boolean indicating success/failure). Personally I'd rather the method not be called on failure, but there may be use cases out there for the second option.
> As an example, it looks like Hibernate's own LuceneEventListener will add a domain object to the index in onPostInsert(PostInsertEvent) even if the insert failed.
> Note that this problem also seems to exist in EntityDeleteAction and EntityUpdateAction (which would mean that Hibernate's LuceneEventListener removes domain objects from the Lucene index even if the delete fails!).
--
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
17 years, 6 months