[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl
by Julien Kronegg (JIRA)
Allow custom Loader in FullTextQueryImpl
----------------------------------------
Key: HSEARCH-349
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349
Project: Hibernate Search
Issue Type: New Feature
Components: query
Affects Versions: 3.1.0.GA
Environment: Hibernate 3.3.1.GA, DB2
Reporter: Julien Kronegg
Priority: Minor
When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code:
List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList();
The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names.
This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene).
Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database.
This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as:
private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) {
if (customLoader!=null) {
customLoader.init(session, sessionFactoryImplementor);
return customLoader;
}
...
}
After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list".
There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2459) Problem with <parent> for 2+ levels of components
by Kevin Bragh (JIRA)
Problem with <parent> for 2+ levels of components
-------------------------------------------------
Key: HHH-2459
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2459
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2, Tested on PostgreSQL and HSQL
Reporter: Kevin Bragh
Attachments: test.zip
I have tested several scenarios similar to the above, and I have searched and posted to the forum with no response.
I have attached the faulty code to the thread.
I have a main class (A) with 3 components recusively included as follows:
A -> B -> C <-> D
In the case above, D has a <parent> property to C.
While loading an instance of A, it seems that D.setC(...) is called with the value of the main class A, and not of parent C.
I don't know if this is a bug, or if parent is not recusively supported.
Any help is appreciated.
Thks, K.
NB: I have tried many different examples (with list and composite-element, etc.) and they all fail with 2+ levels of recursion.
Log
-----
2007-03-01 14:53:07,843 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441277952>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.DefaultSaveOrUpdateEventListener] - <saving transient instance>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <saving [test.hibernate.recurse.A#<null>]>
2007-03-01 14:53:07,843 DEBUG [org.hibernate.event.def.AbstractSaveEventListener] - <executing insertions>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.engine.Versioning] - <using initial version: 0>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Inserting entity: test.hibernate.recurse.A (native id)>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Version: 0>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.SQL] - <insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)>
Hibernate: insert into TEST_A (NO_VERSION, VAL, VAL_B, VAL_C, VAL_D, UID) values (?, ?, ?, ?, ?, null)
2007-03-01 14:53:07,859 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Dehydrating entity: [test.hibernate.recurse.A#<null>]>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 1>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 2>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 3>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 4>
2007-03-01 14:53:07,859 DEBUG [org.hibernate.type.IntegerType] - <binding '0' to parameter: 5>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.SQL] - <call identity()>
Hibernate: call identity()
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.id.IdentifierGeneratorFactory] - <Natively generated identity: 1>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections>
2007-03-01 14:53:07,875 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <commit>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <automatically flushing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <flushing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <processing flush-time cascades>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <dirty checking collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushing entities and processing referenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Processing unreferenced collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Scheduling collection removes/(re)creates/updates>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <Flushed: 0 (re)creations, 0 updates, 0 removals to 0 collections>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <listing entities:>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.pretty.Printer] - <test.hibernate.recurse.A{val=0, b=component[valB,c]{valB=0, c=component[valC,d]{d=component[valD]{valD=0}, valC=0}}, id=1, version=0}>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <executing flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.event.def.AbstractFlushingEventListener] - <post flush>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <before transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <before transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <committed JDBC Connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <aggressively releasing JDBC connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <closing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <returning connection to pool, pool size: 1>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <after transaction completion>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <closing session>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <connection already null in cleanup : no action>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.impl.SessionImpl] - <opened session at timestamp: 4803613441597440>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <begin>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.ConnectionManager] - <opening JDBC connection>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <total checked-out connections: 0>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.connection.DriverManagerConnectionProvider] - <using pooled JDBC connection, pool size: 0>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.transaction.JDBCTransaction] - <current autocommit status: false>
2007-03-01 14:53:07,890 DEBUG [org.hibernate.jdbc.JDBCContext] - <after transaction begin>
2007-03-01 14:53:07,906 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <unable to locate HQL query plan in cache; generating (from test.hibernate.recurse.A)>
2007-03-01 14:53:07,921 DEBUG [org.hibernate.jdbc.ConnectionManager] - <running Session.finalize()>
2007-03-01 14:53:08,000 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <parse() - HQL: from test.hibernate.recurse.A>
2007-03-01 14:53:08,015 DEBUG [org.hibernate.hql.ast.AST] - <--- HQL AST ---
\-[QUERY] 'query'
\-[SELECT_FROM] 'SELECT_FROM'
\-[FROM] 'from'
\-[RANGE] 'RANGE'
\-[DOT] '.'
+-[DOT] '.'
| +-[DOT] '.'
| | +-[IDENT] 'test'
| | \-[IDENT] 'hibernate'
| \-[IDENT] 'recurse'
\-[IDENT] 'A'
>
2007-03-01 14:53:08,031 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,078 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select << begin [level=1, statement=select]>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.tree.FromElement] - <FromClause{level=1} : test.hibernate.recurse.A (no alias) -> a0_>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select : finishing up [level=1, statement=select]>
2007-03-01 14:53:08,093 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <processQuery() : ( SELECT ( FromClause{level=1} TEST_A a0_ ) )>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.HqlSqlWalker] - <Derived SELECT clause created.>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.util.JoinProcessor] - <Using FROM fragment [TEST_A a0_]>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.antlr.HqlSqlBaseWalker] - <select >> end [level=1, statement=select]>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.AST] - <--- SQL AST ---
\-[SELECT] QueryNode: 'SELECT' querySpaces (TEST_A)
+-[SELECT_CLAUSE] SelectClause: '{derived select clause}'
| +-[SELECT_EXPR] SelectExpressionImpl: 'a0_.UID as UID0_' {FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}}
| \-[SQL_TOKEN] SqlFragment: 'a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_'
\-[FROM] FromClause: 'from' FromClause{level=1, fromElementCounter=1, fromElements=1, fromElementByClassAlias=[], fromElementByTableAlias=[a0_], fromElementsByPath=[], collectionJoinFromElementsByPath=[], impliedElements=[]}
\-[FROM_FRAGMENT] FromElement: 'TEST_A a0_' FromElement{explicit,not a collection join,not a fetch join,fetch non-lazy properties,classAlias=null,role=null,tableName=TEST_A,tableAlias=a0_,origin=null,colums={,className=test.hibernate.recurse.A}}
>
2007-03-01 14:53:08,109 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <HQL: from test.hibernate.recurse.A>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] - <SQL: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_>
2007-03-01 14:53:08,125 DEBUG [org.hibernate.hql.ast.ErrorCounter] - <throwQueryException() : no errors>
2007-03-01 14:53:08,140 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <HQL param location recognition took 0 mills (from test.hibernate.recurse.A)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.QueryPlanCache] - <located HQL query plan in cache (from test.hibernate.recurse.A)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.query.HQLQueryPlan] - <find: from test.hibernate.recurse.A>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.QueryParameters] - <named parameters: {}>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open PreparedStatement (open PreparedStatements: 0, globally: 0)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.SQL] - <select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_>
Hibernate: select a0_.UID as UID0_, a0_.NO_VERSION as NO2_0_, a0_.VAL as VAL0_, a0_.VAL_B as VAL4_0_, a0_.VAL_C as VAL5_0_, a0_.VAL_D as VAL6_0_ from TEST_A a0_
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <preparing statement>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to open ResultSet (open ResultSets: 0, globally: 0)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <processing result set>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result set row: 0>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.LongType] - <returning '1' as column: UID0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <result row: EntityKey[test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <Initializing object from ResultSet: [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.persister.entity.AbstractEntityPersister] - <Hydrating entity: [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: NO2_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL4_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL5_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.type.IntegerType] - <returning '0' as column: VAL6_0_>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <Version: 0>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <done processing result set (1 rows)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close ResultSet (open ResultSets: 1, globally: 1)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <about to close PreparedStatement (open PreparedStatements: 1, globally: 1)>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.jdbc.AbstractBatcher] - <closing statement>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.loader.Loader] - <total objects hydrated: 1>
2007-03-01 14:53:08,156 DEBUG [org.hibernate.engine.TwoPhaseLoad] - <resolving associations for [test.hibernate.recurse.A#1]>
2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <IllegalArgumentException in class: test.hibernate.recurse.D, setter method of property: c>
2007-03-01 14:53:08,156 ERROR [org.hibernate.property.BasicPropertyAccessor] - <expected type: test.hibernate.recurse.C, actual value: test.hibernate.recurse.A>
Exception stack trace
-----------------------------
Exception in thread "main" org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.hibernate.recurse.D.c
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104)
at org.hibernate.tuple.PojoComponentTuplizer.setParent(PojoComponentTuplizer.java:132)
at org.hibernate.type.ComponentType.instantiate(ComponentType.java:438)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:524)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:528)
at org.hibernate.type.ComponentType.resolve(ComponentType.java:528)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:113)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223)
at org.hibernate.loader.Loader.doList(Loader.java:2147)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2026)
at org.hibernate.loader.Loader.list(Loader.java:2021)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:369)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:298)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:137)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1014)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at test.hibernate.recurse.Main.main(Main.java:67)
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42)
... 18 more
--
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, 4 months
[Hibernate-JIRA] Created: (HSEARCH-183) @IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields
by Stephane Epardaud (JIRA)
@IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields
----------------------------------------------------------------------------------------
Key: HSEARCH-183
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-183
Project: Hibernate Search
Issue Type: Improvement
Components: mapping
Affects Versions: 3.0.1.GA
Reporter: Stephane Epardaud
If all my entities have their ID property named "id" and they use @IndexedEmbedded(prefix="") then there will be several fields named "id" per document.
This results in very unfortunate behaviour when indexes are updated because this id is then used by HS to remove Lucene documents, so instead of removing only the one document we are updating, HS removes all documents whose ID have been embedded in the index.
We use prefix="" in order to accumulate embedded entities' "text" fields into the root entity so that we can search on any "text" field, embedded or not. This is required because there seems to be no support for a term wildcard such as "*.text:foo" which would search on any term ending by ".text" for the string "foo".
Either prefix="" is supported, and this behaviour should be changed, or at the very least trigger a visible warning, or it is not supported and it should be documented and an exception should be thrown.
Since it is behaviour I need, I favour supporting it, so I've patched DocumentBuilder to store the ID of the root entity in a special field like _hibernate_class, so that when we update the index only the appropriate entity index document is removed. This works well, but has the side-effect of ignoring the name of the ID as specified in @DocumentId.
An alternative would be to still store the root ID is a "special" field, and keep storing the ID under a field name as specified by the user. As long as we only use the "special" ID for index updating all will work well.
I can produce both patches and documentation if you agree (and choose).
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-5086) "ambiguous column" SQL errors in Hibernate 3.5.0 Final
by dnalos (JIRA)
"ambiguous column" SQL errors in Hibernate 3.5.0 Final
------------------------------------------------------
Key: HHH-5086
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5086
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Final
Environment: Java JDK 1.6.0_19
Hibernate Core 3.5.0 Final
hibernate-jpa-2.0-api-1.0.0.Final.jar
mysql-connector-java-5.1.10-bin.jar
Reporter: dnalos
Attachments: HibernateAmbiguousTest.zip
After update Hibernate Core to 3.5, we get some Exception like this:
Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101)
We create a testcase for you, and the Exception from the testcase:
ERROR 15:39:28 0 Column '_value' in field list is ambiguous (JDBCExceptionReporter.java:101)
org.hibernate.exception.ConstraintViolationException: could not load an entity: [Invoice#401]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1937)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3270)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1080)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:997)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:990)
at HibernateAmbiguousTest.testAmbiguous(HibernateAmbiguousTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Column '_value' in field list is ambiguous
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)
at com.mysql.jdbc.Util.getInstance(Util.java:381)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1015)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3558)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3490)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1959)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2109)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2648)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2077)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2228)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1849)
at org.hibernate.loader.Loader.doQuery(Loader.java:718)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1933)
... 34 more
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
by Dan Bisalputra (JIRA)
Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
-----------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC
Reporter: Dan Bisalputra
Priority: Minor
When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context.
This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3637) Union in where doesn't works for Sybase, need to evict test case
by Juraci Paixao Krohling (JIRA)
Union in where doesn't works for Sybase, need to evict test case
----------------------------------------------------------------
Key: HHH-3637
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3637
Project: Hibernate Core
Issue Type: Improvement
Components: testsuite
Environment: Sybase ASE 15.0.2
Reporter: Juraci Paixao Krohling
Assignee: Juraci Paixao Krohling
It seems that Sybase doesn't supports UNION inside WHERE clauses, causing the test DynamicFilterTest#testSqlSyntaxOfFiltersWithUnions to fail. The scenario for this test case is not described in the documentation, but I would expect it to work:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter....
The query is:
select
category0_.CAT_ID as CAT1_6_,
category0_.name as name6_,
category0_.eff_start_dt as eff3_6_,
category0_.eff_end_dt as eff4_6_
from
CATEGORY category0_
where
'abc' in (
select
d.reg
from
department d
where
(
d.dept_id=123
)
union
select
p.name
from
sales_person p
)
If executed only the queries from inside the where clause (the two selects with union), it works as expected. Also, if removed the union and one of the queries inside the where, it works as expected. So, the problem happens only when using union inside a where clause.
For now, I'd suggest to evict this test for Sybase.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws
by Jeppe N. Madsen (JIRA)
Connection leak if logAndClearWarnings throws
----------------------------------------------
Key: HHH-2447
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3, 3.2.2
Environment: Database product name : DB2/NT
Database product version : SQL08025
JDBC driver name : IBM DB2 JDBC Universal Driver Architecture
Hibernate 3.1.3 (seems to exist in 3.2.2 as well)
JDBC driver version : 2.9.31
Reporter: Jeppe N. Madsen
Priority: Minor
In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed.
We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong:
[14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning
at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33)
at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22)
at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293)
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem
by Sandeep Vaid (JIRA)
one-to-one: foreign key: save Problem
-------------------------------------
Key: HHH-4015
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Reporter: Sandeep Vaid
Priority: Critical
I have one-to-one relationship between class A and class B
<class name="A" table="TEMPA" >
<id name="aaId" type="string" column="AID" length="10">
<generator class="assigned"></generator>
</id>
<one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" />
</class>
<class name="B" table="TEMPB" lazy="true">
<id name="baId" type="string" column="BID" length="10">
<generator class="foreign">
<param name="property">a</param>
</generator>
</id>
<one-to-one name="a" class="A" />
</class>
Problem 1: When i try to save A, it fires :
insert into HBLEARN1.TEMPB (BID) values ('1')
and throws error :
The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the
parent key of the parent table. SQLSTATE=23503
Why it is first trying to save 'B' instead of 'A' first ?
Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml,
It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect..
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</code>
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
by Paul Cowan (JIRA)
Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
--------------------------------------------------------------------------------
Key: HHH-3102
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Paul Cowan
Priority: Minor
Attachments: HibernateKeyPoolTest.java
Hi all,
Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though.
Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool.
A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows:
*** After creation
Mouth (id=null) has teeth [canine(id=null)]
*** Save
Mouth (id=1) has teeth [canine(id=2)]
*** Flush
Hibernate: insert into Mouth (id) values (?)
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2)]
*** Add new
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Save again
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Flush again
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2), molar(id=3)]
As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good.
However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed.
While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not.
There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.
by Philip R. "Pib" Burns (JIRA)
Long "in" lists in queries results in a Java stack overflow exception.
----------------------------------------------------------------------
Key: HHH-2166
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris)
Reporter: Philip R. "Pib" Burns
Attachments: NodeTraverser.java
With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like
where x in (:x)
or a manually constructed
where x in (1,2,3 .....)
can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.
The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.
The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-4577) 2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache
by Guenther Demetz (JIRA)
2L query cache: Low performance of flush and commit due many unnecessary (pre)invalidate calls on UpdateTimestampsCache
-----------------------------------------------------------------------------------------------------------------------
Key: HHH-4577
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4577
Project: Hibernate Core
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.2
Environment: Hibernate 3.3.2GA with JBossCache3.2.1.GA as 2L-cache provider
SQLServer2008
Reporter: Guenther Demetz
Analyzing what our application is mainly doing during flush/commit,
we saw that very often the concerning thread is executing in jbosscache stuff (see 2 sample stacktraces below).
Analyzing the code we discovered that, if doing 1000 inserts for a determinate entity:
-on flush UpdateTimestampsCache.preinvalidate() is called 1000 times for the same space (=table)
-on commit UpdateTimestampsCache.invalidate() is called another 1000 times again for the same space (=table)
It would be much smarter to collect the interested spaces once per flush and once per commit and then execute the (pre)invalidate once per single space. In the case above it would reduce the calls to one single UpdateTimestampsCache.preinvalidate()call on flush and one single UpdateTimestampsCache.invalidate() on commit.
For the commit the enhancement could be following:
ActionQueue.java:
public void afterTransactionCompletion(boolean success) {
int size = executions.size();
final boolean invalidateQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
Set<Serializable> spaces = invalidateQueryCache ? new HashSet<Serializable>() : null;
try {
for ( int i = 0; i < size; i++ ) {
try {
Executable exec = ( Executable ) executions.get( i );
if ( invalidateQueryCache ) {
Serializable[] nspaces = exec.getPropertySpaces();
for (int j=0; j < nspaces.length; j++)
spaces.add(nspaces[j]);
}
exec.afterTransactionCompletion( success );
}
catch ( CacheException ce ) {
log.error( "could not release a cache lock", ce );
// continue loop
}
catch ( Exception e ) {
throw new AssertionFailure( "Exception releasing cache locks", e );
}
}
}
finally {
session.getFactory().getUpdateTimestampsCache().invalidate(spaces.toArray(new Serializable[]{}));
}
executions.clear();
}
Stack traces:
java.lang.Thread.isInterrupted(Native Method)
java.lang.Thread.interrupted(Thread.java:873)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1134)
java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:312)
java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:241)
org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:249)
org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:234)
org.jboss.cache.interceptors.EvictionInterceptor.registerEvictionEventToRegionManager(EvictionInterceptor.java:252)
org.jboss.cache.interceptors.EvictionInterceptor.visitPutKeyValueCommand(EvictionInterceptor.java:109)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:102)
org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555)
org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212)
org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128)
org.hibernate.cache.UpdateTimestampsCache.preinvalidate(UpdateTimestampsCache.java:70)
- locked org.hibernate.cache.UpdateTimestampsCache@1afcaae
org.hibernate.engine.ActionQueue.execute(ActionQueue.java:275)
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
Stack trace:
java.lang.Thread.isInterrupted(Native Method)
java.lang.Thread.interrupted(Thread.java:873)
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1158)
java.util.concurrent.locks.ReentrantLock.tryLock(ReentrantLock.java:416)
org.jboss.cache.util.concurrent.locks.AbstractSharedLockContainer.acquireLock(AbstractSharedLockContainer.java:94)
org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:133)
org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:157)
org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217)
org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101)
org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301)
org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283)
org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82)
org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555)
org.hibernate.cache.jbc2.util.CacheHelper.put(CacheHelper.java:212)
org.hibernate.cache.jbc2.timestamp.TimestampsRegionImpl.put(TimestampsRegionImpl.java:128)
org.hibernate.cache.UpdateTimestampsCache.invalidate(UpdateTimestampsCache.java:85)
- locked org.hibernate.cache.UpdateTimestampsCache@1afcaae
org.hibernate.engine.ActionQueue.afterTransactionCompletion(ActionQueue.java:202)
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3850) org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
by wu bin (JIRA)
org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3850
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3850
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.6
Environment: linux , oracle 9.2 jboss 4.2.3
Reporter: wu bin
we use hibernate and jboss tree cache in jboss 4.2.3 in lnux.
we only have 1 node in the cluster.
we met this exception:
19:00:58,515 ERROR [TxInterceptor] method invocation failed
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
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:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 ERROR [TxInterceptor] prepare method invocation failed
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
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:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 WARN [TreeCache] replication failure with method_call prepare; id:10; Args: ( arg[0] = GlobalTransaction:<16.173.241.57:9242>:119 ...) exception
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
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:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete
by Markus Heiden (JIRA)
refresh throws exception when database has been altered with a delete
---------------------------------------------------------------------
Key: HHH-2305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle 9.2
Reporter: Markus Heiden
Attachments: hibernate.zip
First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead.
Test case is attached. Stacktrace of test case:
Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=?
org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003]
at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
at hibernate.refresh.Test.main(Test.java:46)
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data
by Manuel Dominguez Sarmiento (JIRA)
Custom Oracle Batcher to allow batch updates for versioned data
---------------------------------------------------------------
Key: HHH-3360
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga
Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work)
Reporter: Manuel Dominguez Sarmiento
Priority: Minor
Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java
We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates.
Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates.
We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection.
Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0.
A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface.
There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface.
Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#...
As expected, implementing this solution has resulted in drastical improvement in batch processing.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
by Gail Badner (JIRA)
Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
--------------------------------------------------------------------------------------------------
Key: HHH-3160
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160
Project: Hibernate3
Issue Type: Sub-task
Reporter: Gail Badner
Assignee: Gail Badner
The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table..
Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint.
See HHH-1268 for a description of how to reproduce this issue.
For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded.
For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration
by Helmut Pasch (JIRA)
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3410) @OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false)
by Kamil Morong (JIRA)
@OneToMany forces unique key in @JoinTable when inverseJoinColumns = @JoinColumn(unique=false)
----------------------------------------------------------------------------------------------
Key: HHH-3410
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3410
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: MySQL 5.0.51b, Hibernate Core 3.2.6 GA, Hibernate Annotations 3.3.1 GA
Reporter: Kamil Morong
Hi,
I need to have this class composition with one to many relation:
@Entity
@Table(name="USER")
public class User implements java.io.Serializable {
private Long id;
private String username;
private String password;
private Set<Role> roles = new LinkedHashSet<Role>();
public User() {
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "USER_ID")
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@Column(name="USERNAME", nullable=false, unique=true)
public String getUsername() {
return username;
}
public void setUsername(String userName) {
this.username = userName;
}
@Column(name="PASSWORD", nullable=false)
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
@CollectionOfElements
@OneToMany(cascade={CascadeType.PERSIST, CascadeType.MERGE})
@JoinTable(name = "USER_ROLE",
joinColumns = @JoinColumn(name = "USER_ID", unique=false),
inverseJoinColumns = @JoinColumn(name = "ROLE_ID", unique=false))
@Cascade(org.hibernate.annotations.CascadeType.SAVE_UPDATE)
@LazyCollection(LazyCollectionOption.FALSE)
public Set<Role> getRoles() {
return roles;
}
public void setRoles(Set<Role> roles) {
this.roles = roles;
}
}
@Entity
@Table(name="ROLE")
public class Role implements java.io.Serializable {
private Long id;
private String name;
public Role() {
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "ROLE_ID")
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@Column(name="NAME", nullable=false, unique=true)
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
This will create db tables like SQL script
CREATE TABLE `user` (
`USER_ID` BIGINT(20) NOT NULL AUTO_INCREMENT,
`PASSWORD` VARCHAR(255) NOT NULL DEFAULT '',
`USERNAME` VARCHAR(255) NOT NULL DEFAULT '',
PRIMARY KEY (`USER_ID`),
UNIQUE KEY `USERNAME` (`USERNAME`)
);
CREATE TABLE `role` (
`ROLE_ID` BIGINT(20) NOT NULL AUTO_INCREMENT,
`NAME` VARCHAR(255) NOT NULL DEFAULT '',
PRIMARY KEY (`ROLE_ID`),
UNIQUE KEY `NAME` (`NAME`)
);
CREATE TABLE `user_role` (
`USER_ID` BIGINT(20) NOT NULL,
`ROLE_ID` BIGINT(20) NOT NULL,
PRIMARY KEY (`USER_ID`, `ROLE_ID`),
UNIQUE KEY `ROLE_ID` (`ROLE_ID`),
KEY `FKBC16F46A1174FFAB` (`ROLE_ID`),
KEY `FKBC16F46AB69FC38B` (`USER_ID`),
CONSTRAINT `FKBC16F46AB69FC38B` FOREIGN KEY (`USER_ID`) REFERENCES `user` (`USER_ID`),
CONSTRAINT `FKBC16F46A1174FFAB` FOREIGN KEY (`ROLE_ID`) REFERENCES `role` (`ROLE_ID`)
);
Tables USER and ROLE are right, but the join table USER_ROLE still have defined UNIQUE KEY `ROLE_ID` (`ROLE_ID`).
This causes there cannot be one user with many roles.
There must be some bug while generating database scheme. I am not able to remove unique key.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3716) Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL
by Gail Badner (JIRA)
Sybase - null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL
----------------------------------------------------------------------------------------------
Key: HHH-3716
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3716
Project: Hibernate Core
Issue Type: Bug
Components: core
Environment: Sybase
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.2.x, 3.3.x, 3.4
Null values for columns mapped as "boolean" are persisted as 0 (zero) instead of NULL. This happens because Hibernate persists a null Boolean value by calling:
PreparedStatement.setNull( index, java.sql.Types.BIT )
The SQL code, java.sql.Types.BIT, is used because the Hibernate BooleanType defines its code as java.sql.Type.BIT.
Sybase JDBC converts the null to 0, apparently because Sybase does not allow nullable bit columns.
This can be reproduced using an annotations unit test, Java5FeaturesTest.testAutoboxing()..
Sybase maps bit columns to tinyint, so when the unit test is executed, the column in the underlying table is actually of type tinyint, not bit. Sybase allows nullable tinyint columns, so there should be no problem persisting a null value as null.
I've verified that changing the call to:
PreparedStatement.setNull( index, java.sql.Types.TINYINT )
persists the null value without being converted to 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
14 years, 6 months
[Hibernate-JIRA] Created: (HHH-3843) @Audited and @ManyToMany relation problem - after modyfing an Entity: org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session ...
by Michał Maryniak (JIRA)
@Audited and @ManyToMany relation problem - after modyfing an Entity: org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session ...
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3843
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3843
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.1
Environment: envers.jar 1.2.0, Hibernate 3.3.1, postgresql-8.3, jboss-4.2.3
Reporter: Michał Maryniak
Attachments: enverse.7z
There is a problem with unidirectional @ManyToMany relation.
This case is different than the one with inheritance: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3830.
The example is trival and code is as simple as it can be.
A single Person can have many roles, and one Role can by assigned to many Person entities.
@Entity
@Audited
public class Person implements Serializable {
(...)
@ManyToMany
public List<Role> getRoles() {
return roles;
}
(...)
}
and
@Entity
@Audited
public class Role implements Serializable {
(...)
}
And here comes a use case:
1) I create role 'admin'
2) I create role 'user'
3) I create person 'john' and add him a role 'admin'
4) I edit 'john' and add him second role 'user'
and I got an exception:
org.hibernate.NonUniqueObjectException with message: "a different object with the same identifier value was already associated with the session: [Person_Role_AUD#{roles_id=1, Person_id=5, REV=DefaultRevisionEntity(id = 7, revisionDate = 2009-04-01 10:46:32)}]"
If I add one role and remove the second one, or if I only remove a role - an Exception does not occur.
I attached a zip file with this simple SEAM project generated by seam-gen 2.1.1 GA.
I haven't included jar files, but project requires jar's "generated" with seam-gen (2.1.1) and following jar's have been replaced with new ones:
2008-06-13 13:09 313˙898 dom4j.jar 1.6.1
2009-03-23 13:01 285˙158 envers.jar 1.2.0-hibernate-3.3
2008-08-20 11:27 279˙714 hibernate-annotations.jar 3.4.0.GA
2008-08-20 11:31 66˙993 hibernate-commons-annotations.jar 3.1.0.GA
2008-08-20 12:19 119˙292 hibernate-entitymanager.jar 3.4.0.GA
2008-12-04 14:39 304˙236 hibernate-search.jar 3.1.0.GA
2008-09-10 14:01 62˙574 hibernate-validator.jar 3.1.0.GA
2008-09-10 13:27 2˙766˙130 hibernate.jar from hibernate-distribution-3.3.1.GA-dist
2008-06-13 13:09 13˙236 jta.jar 1.1 (from hibernate-distribution-3.3.1.GA-dist)
2008-12-04 14:41 818˙961 lucene-core.jar 2.4.0 701827 - 2008-10-05 16:44:37
2008-08-19 20:40 17˙384 slf4j-api.jar 1.5.2
If you wish - I can attach a file with my oryginal jar - but it would be a realy big file ;-)
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3440) 3.3.0 GA with MySQL 5.0 throws table validation exception
by Carlo Luib-Finetti (JIRA)
3.3.0 GA with MySQL 5.0 throws table validation exception
---------------------------------------------------------
Key: HHH-3440
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3440
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.3.0.GA
Environment: Hibernate 3.3.0 GA
MySQL 5.0
JBoss 4.2.2
Reporter: Carlo Luib-Finetti
Hibernate immediately throws an exception at application startup, when it does the schema validation.
org.hibernate.HibernateException: Wrong column type in dpjw.assessment for column NOTES. Found: text, expected: longtext
Comparing the sources of 3.2.0 with 3.3.0 I can see that someone set two java statements into comment. The 3.2 version of MySQLDialect.java looks like this:
protected void registerVarcharTypes() {
registerColumnType( Types.VARCHAR, "longtext" );
registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
registerColumnType( Types.VARCHAR, 65535, "text" );
registerColumnType( Types.VARCHAR, 255, "varchar($l)" );
}
while the new 3.3.0 version is this:
protected void registerVarcharTypes() {
registerColumnType( Types.VARCHAR, "longtext" );
// registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
// registerColumnType( Types.VARCHAR, 65535, "text" );
registerColumnType( Types.VARCHAR, 255, "varchar($l)" );
}
If I uncomment these (and others in the same Java file!), the validation process is ok.
Is there any reason why these statements (and others!) were commented out???
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3530) The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA
by Geoffrey De Smet (JIRA)
The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA
--------------------------------------------------------------------------------------------------------------------------
Key: HHH-3530
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3530
Project: Hibernate Core
Issue Type: Bug
Components: build
Affects Versions: 3.3.1
Reporter: Geoffrey De Smet
Here's the proof:
http://fisheye.jboss.org/browse/Hibernate/core/tags/hibernate-3.3.1.GA/co...
contains the lines (44-45):
registerColumnType( Types.CLOB, "longtext" );
registerColumnType( Types.CLOB, 16777215, "mediumtext" );
registerColumnType( Types.CLOB, 65535, "text" );
But the sources jar downloaded from
http://repository.jboss.org/maven2/org/hibernate/hibernate-core/3.3.1.GA/...
file
org\hibernate\dialect\MySQLDialect.java
so on my pc
C:\Documents and Settings\gds\.m2\repository\org\hibernate\hibernate-core\3.3.1.GA\hibernate-core-3.3.1.GA-sources.jar!\org\hibernate\dialect\MySQLDialect.java
has these lines (66-68) instead:
registerColumnType( Types.CLOB, "longtext" );
// registerColumnType( Types.CLOB, 16777215, "mediumtext" );
// registerColumnType( Types.CLOB, 65535, "text" );
It's not just some copyright stuff that been added (giving it different line numbers), some lines are clearly commented out.
Maybe untagged changes happened in other files too?
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3930) one-to-one causes redundant select query
by Martijn Dashorst (JIRA)
one-to-one causes redundant select query
----------------------------------------
Key: HHH-3930
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3930
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Martijn Dashorst
@Entity
public class Address {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@OneToOne(mappedBy = "address")
private Customer customer;
}
@Entity
public class Customer {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
@OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL)
private Address address = new Address();
public Long getId() {
return id;
}
public Address getAddress() {
return address;
}
}
This mapping causes 2 instead of the expected 1 query to retrieve a Customer and its Address from the db:
select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.id=?
select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.address_id=?
Changing the mapping to a LAZY fetch type:
@OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
private Address address = new Address();
Causes 3 select queries instead of the expected 2 queries to retrieve a Customer (and its Address) from the db:
select * from Customer customer0_ where customer0_.id=?
select * from Address address0_ left outer join Customer customer1_ on address0_.id=customer1_.address_id where address0_.id=?
select * from Customer customer0_ where customer0_.address_id=?
The third select is superfluous because the relationship is already completely known: you already have the customer, so why not just set it on the address entity?
Making the address field in Customer a @ManyToOne doesn't make a difference.
Making the customer field in Address a @OneToMany does remove the extra select, but forces our model to change the relationship from Customer to List<Customer> where we *know* there'll be only 1 element.
Apparently Hibernate can figure out the reverse relationship with a @ManyToOne - @OneToMany without the need for additional queries, can't this be extended to @OneToOne bidirectional relationships as well?
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-4881) restrict polymorphic query results
by Domenico Loiacono (JIRA)
restrict polymorphic query results
----------------------------------
Key: HHH-4881
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4881
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Beta-4
Environment: Hibernate 3.5.0-Beta-4, MySQL 5.1 Glassfish v3
Reporter: Domenico Loiacono
I'm using JPA 2.0, Hibernate 3.5.0-Beta4, MySQL 5.1 on Glassfish v3.
I want to limit the polymorphic query results using JPA 2.0 syntax (TYPE) :
SELECT e FROM Employee e WHERE TYPE(e) IN (FullTime, Executive)
but it seems that Hibernate 3.5.0-Beta4 doesn't support this syntax because in the generated sql query the 'type' keyword remains unmapped and MySQL throws an Exception:
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(type(employee0_.id) in (5))' at line 1
So I tried with Criteria API:
CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
CriteriaQuery<Employee> criteria = criteriaBuilder.createQuery(Employee.class);
Root<Employee> employee= criteria.from(Employee.class);
criteria.where(employee.type().in(FullTime.class,Executive.class));
But I received an Exception:
Caused by: java.lang.IllegalArgumentException: Unexpected call on EntityTypeExpression#render
at org.hibernate.ejb.criteria.expression.PathTypeExpression.render(PathTypeExpression.java:48)
at org.hibernate.ejb.criteria.predicate.InPredicate.render(InPredicate.java:164)
at org.hibernate.ejb.criteria.QueryStructure.render(QueryStructure.java:258)
at org.hibernate.ejb.criteria.CriteriaQueryImpl.render(CriteriaQueryImpl.java:340)
at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:150)
at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:416)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.createQuery(EntityManagerWrapper.java:489)
So I opened the PathTypeExpression class and in the render method I saw :
public String render(CriteriaQueryCompiler.RenderingContext renderingContext) {
// todo : is it valid for this to get rendered into the query itself?
throw new IllegalArgumentException( "Unexpected call on EntityTypeExpression#render" );
}
Then I switched to use Hibernate custom query syntax (class) :
SELECT e FROM Employee e WHERE (e.class) IN (FullTime, Executive)
Ok this works fine.
But when I add a join with another entity (Department) that has the same TABLE_PER_CLASS inheritance strategy of entity Employee, I have a new problem:
SELECT e FROM Employee e JOIN e.departments d WHERE d.code = 'D1' and (e.class) IN (FullTime, Executive)
GRAVE: Column 'clazz_' in where clause is ambiguous
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute query
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-2866) The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order.
by Benjamin Keil (JIRA)
The order of parameters is not maintained between HQL and SQL, but the parameters are inserted into the PreparedStatement in their HQL order.
---------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2866
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2866
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5.ga; both with MySQLInnoDB and H2 dialects; both with annotations and hand written mapping files
Reporter: Benjamin Keil
Attachments: ReorderedParameters.java, ReorderedParameters.zip
The HQL query
from Assoc a where a.type.oid = ? and a.constituents[?].oid = ?
gets translated into
select
reorderedp0_.oid as oid1_,
reorderedp0_.type_oid as type2_1_
from
Assoc reorderedp0_,
Assoc_Topic constituen1_,
Topic reorderedp2_
where
reorderedp0_.oid=constituen1_.Assoc_oid
and constituen1_.topic_index = ?
and constituen1_.constituents_oid=reorderedp2_.oid
and reorderedp0_.type_oid=?
and reorderedp2_.oid=?
Where clearly the first and second parameters (the index and the type) have been permuted.
The relevant thread in the User forum is : http://forum.hibernate.org/viewtopic.php?t=979832
Attached are a java source file that demonstrates the error, and a zipped maven2 project that supplies the Hibernate, Hibernate-Annotation, H2, and Log4J dependencies.
--
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, 6 months
[Hibernate-JIRA] Created: (HSEARCH-46) Race condition in manual index update
by Christian Bauer (JIRA)
Race condition in manual index update
-------------------------------------
Key: HSEARCH-46
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-46
Project: Hibernate Search
Issue Type: Bug
Components: engine
Reporter: Christian Bauer
log.info("rebuilding Lucene index");
Class[] entityTypes = { Document.class, File.class, Comment.class, Faq.class};
EntityManager em = (EntityManager) Component.getInstance("entityManager");
FullTextSession ftSession = org.hibernate.search.Search.createFullTextSession( (Session) em.getDelegate() );
for (Class entityType : entityTypes) {
for (Object o : ((Session) em.getDelegate()).createCriteria(entityType).list()) {
ftSession.index(o);
}
}
08:23:39,419 INFO [WikiInit] rebuilding Lucene index
08:23:39,532 DEBUG [ManagedPersistenceContext] created seam managed persistence context from EntityManagerFactory
08:23:39,553 INFO [STDOUT] Hibernate: /* criteria query */ select this_.NODE_ID as NODE2_1_1_, this_.AREA_NR as AREA3_1_1_, this_.CREATED_BY_USER_ID as CREATED17_1_1_, this_.CREATED_ON as CREATED4_1_1_, this_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, this_.LAST_MODIFIED_ON as LAST5_1_1_, this_.MENU_ITEM as MENU6_1_1_, this_.NAME as NAME1_1_, this_.PARENT_NODE_ID as PARENT20_1_1_, this_.READ_ACCESS_LEVEL as READ8_1_1_, this_.NODE_REVISION as NODE9_1_1_, this_.OBJ_VERSION as OBJ10_1_1_, this_.WIKINAME as WIKINAME1_1_, this_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, this_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, this_.ENABLE_COMMENTS as ENABLE15_1_1_, this_.NAME_AS_TITLE as NAME16_1_1_, node2_.NODE_ID as NODE2_1_0_, node2_.AREA_NR as AREA3_1_0_, node2_.CREATED_BY_USER_ID as CREATED17_1_0_, node2_.CREATED_ON as CREATED4_1_0_, node2_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node2_.LAST_MODIFIED_ON as LAST5_1_0_, node2_.MENU_ITEM as MENU6_1_0_, node2_.NAME as NAME1_0_, node2_.PARENT_NODE_ID as PARENT20_1_0_, node2_.READ_ACCESS_LEVEL as READ8_1_0_, node2_.NODE_REVISION as NODE9_1_0_, node2_.OBJ_VERSION as OBJ10_1_0_, node2_.WIKINAME as WIKINAME1_0_, node2_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node2_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node2_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node2_.ENABLE_COMMENTS as ENABLE15_1_0_, node2_.NAME_AS_TITLE as NAME16_1_0_, node2_1_.CONTENT_TYPE as CONTENT1_2_0_, node2_1_.FILENAME as FILENAME2_0_, node2_1_.FILESIZE as FILESIZE2_0_, node2_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node2_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node2_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node2_.NODE_TYPE as NODE1_1_0_ from NODE this_ left outer join NODE node2_ on this_.PARENT_NODE_ID=node2_.NODE_ID left outer join NODE_FILE node2_1_ on node2_.NODE_ID=node2_1_.FILE_ID where this_.NODE_TYPE='DOCUMENT'
08:23:39,587 INFO [STDOUT] Hibernate: /* load org.jboss.seam.wiki.core.model.Node */ select node0_.NODE_ID as NODE2_1_1_, node0_.AREA_NR as AREA3_1_1_, node0_.CREATED_BY_USER_ID as CREATED17_1_1_, node0_.CREATED_ON as CREATED4_1_1_, node0_.LAST_MODIFIED_BY_USER_ID as LAST18_1_1_, node0_.LAST_MODIFIED_ON as LAST5_1_1_, node0_.MENU_ITEM as MENU6_1_1_, node0_.NAME as NAME1_1_, node0_.PARENT_NODE_ID as PARENT20_1_1_, node0_.READ_ACCESS_LEVEL as READ8_1_1_, node0_.NODE_REVISION as NODE9_1_1_, node0_.OBJ_VERSION as OBJ10_1_1_, node0_.WIKINAME as WIKINAME1_1_, node0_.WRITE_ACCESS_LEVEL as WRITE12_1_1_, node0_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_1_, node0_.ENABLE_COMMENT_FORM as ENABLE14_1_1_, node0_.ENABLE_COMMENTS as ENABLE15_1_1_, node0_.NAME_AS_TITLE as NAME16_1_1_, node0_1_.CONTENT_TYPE as CONTENT1_2_1_, node0_1_.FILENAME as FILENAME2_1_, node0_1_.FILESIZE as FILESIZE2_1_, node0_1_.IMAGE_SIZE_X as IMAGE5_2_1_, node0_1_.IMAGE_SIZE_Y as IMAGE6_2_1_, node0_1_.IMAGE_THUMBNAIL as IMAGE7_2_1_, node0_.NODE_TYPE as NODE1_1_1_, node1_.NODE_ID as NODE2_1_0_, node1_.AREA_NR as AREA3_1_0_, node1_.CREATED_BY_USER_ID as CREATED17_1_0_, node1_.CREATED_ON as CREATED4_1_0_, node1_.LAST_MODIFIED_BY_USER_ID as LAST18_1_0_, node1_.LAST_MODIFIED_ON as LAST5_1_0_, node1_.MENU_ITEM as MENU6_1_0_, node1_.NAME as NAME1_0_, node1_.PARENT_NODE_ID as PARENT20_1_0_, node1_.READ_ACCESS_LEVEL as READ8_1_0_, node1_.NODE_REVISION as NODE9_1_0_, node1_.OBJ_VERSION as OBJ10_1_0_, node1_.WIKINAME as WIKINAME1_0_, node1_.WRITE_ACCESS_LEVEL as WRITE12_1_0_, node1_.DEFAULT_DOCUMENT_ID as DEFAULT19_1_0_, node1_.ENABLE_COMMENT_FORM as ENABLE14_1_0_, node1_.ENABLE_COMMENTS as ENABLE15_1_0_, node1_.NAME_AS_TITLE as NAME16_1_0_, node1_1_.CONTENT_TYPE as CONTENT1_2_0_, node1_1_.FILENAME as FILENAME2_0_, node1_1_.FILESIZE as FILESIZE2_0_, node1_1_.IMAGE_SIZE_X as IMAGE5_2_0_, node1_1_.IMAGE_SIZE_Y as IMAGE6_2_0_, node1_1_.IMAGE_THUMBNAIL as IMAGE7_2_0_, node1_.NODE_TYPE as NODE1_1_0_ from NODE node0_ left outer join NODE_FILE node0_1_ on node0_.NODE_ID=node0_1_.FILE_ID left outer join NODE node1_ on node0_.PARENT_NODE_ID=node1_.NODE_ID left outer join NODE_FILE node1_1_ on node1_.NODE_ID=node1_1_.FILE_ID where node0_.NODE_ID=?
08:23:39,654 INFO [STDOUT] Hibernate: /* criteria query */ select this_.COMMENT_ID as COMMENT1_4_0_, this_.CREATED_ON as CREATED2_4_0_, this_.DOCUMENT_ID as DOCUMENT9_4_0_, this_.FROM_USER_EMAIL as FROM3_4_0_, this_.FROM_USER_HOMEPAGE as FROM4_4_0_, this_.FROM_USER_NAME as FROM5_4_0_, this_.SUBJECT as SUBJECT4_0_, this_.COMMENT_TEXT as COMMENT7_4_0_, this_.OBJ_VERSION as OBJ8_4_0_ from COMMENTS this_
08:23:39,662 INFO [STDOUT] Hibernate: /* criteria query */ select this_.FAQ_ID as FAQ1_7_0_, this_.ANSWER as ANSWER7_0_, this_.CREATED_ON as CREATED3_7_0_, this_.QUESTION as QUESTION7_0_, this_.RATING as RATING7_0_, this_.OBJ_VERSION as OBJ6_7_0_ from FAQ this_
08:23:39,665 DEBUG [Work] committing transaction
08:23:39,807 ERROR [AssertionFailure] an assertion failure occured (this may indicate a bug in Hibernate)
org.hibernate.annotations.common.AssertionFailure: Tries to read for update a index while a writer is accessedclass org.jboss.seam.wiki.core.model.Document
at org.hibernate.search.backend.Workspace.getIndexReader(Workspace.java:54)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.remove(LuceneWorker.java:81)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:69)
at org.hibernate.search.backend.impl.lucene.LuceneWorker.performWork(LuceneWorker.java:40)
at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor.run(LuceneBackendQueueProcessor.java:36)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.performWork(BatchedQueueingProcessor.java:116)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.afterCompletion(PostTransactionWorkQueueSynchronization.java:49)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:136)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:342)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:95)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
--
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, 6 months