[Hibernate-JIRA] Created: (HHH-5905) HQL "where in" queries consume near 100% CPU - possibly for hours
by Marcel Stör (JIRA)
HQL "where in" queries consume near 100% CPU - possibly for hours
-----------------------------------------------------------------
Key: HHH-5905
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5905
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.6
Reporter: Marcel Stör
Priority: Critical
[Claim]
The loop in ParameterParser.parse(String, ParameterParser$Recognizer) uses 100% CPU core per thread that executes it since it iterates over a string char by char and calling string operations in the loop.
[Java client]
Query query = getEntityManager().createQuery("select articleNumber from Article where articleNumber in (:articleNumbers)");
query.setParameter("articleNumbers", articleNumbers);
List<ArticleNumber> filteredArticleNumbers = (List<ArticleNumber>) query.getResultList();
[Stacktrace of involved classes/methods]
ParameterParser.parse(String, ParameterParser$Recognizer) line: 88
ParamLocationRecognizer.parseLocations(String) line: 75
HQLQueryPlan.buildParameterMetadata(ParameterTranslations, String) line: 290
HQLQueryPlan.<init>(String, String, boolean, Map, SessionFactoryImplementor) line: 121
HQLQueryPlan.<init>(String, boolean, Map, SessionFactoryImplementor) line: 80
QueryPlanCache.getHQLQueryPlan(String, boolean, Map) line: 98
SessionImpl(AbstractSessionImpl).getHQLQueryPlan(String, boolean) line: 156
SessionImpl.list(String, QueryParameters) line: 1250
QueryImpl.list() line: 102
QueryImpl<X>.getResultList() line: 241
[Observations]
QueryImpl#list() calls SessionImpl#list(String, QueryParameters) passing the *expanded* query:
return getSession().list(expandParameterLists(namedParams), getQueryParameters(namedParams));
Hence, what is passed to SessionImpl#list(String, QueryParameters) in my case is something like:
select articleNumber from Article where articleNumber in (:articleNumbers0_, :articleNumbers1_, :articleNumbers2_, :articleNumbers3_, :articleNumbers4_, :articleNumbers5_, :articleNumbers6_,
Now imagine how long that query string is when the "where in" query has a few thousand article numbers. org.hibernate.engine.query.ParameterParser.parse(String, Recognizer) then iterates over each character in the query string and calls StringHelper.firstIndexOfChar() for each named parameter. Even on fast servers this operation may easily take half an hour or more (mind you it's a blocking call!) if the expanded query string has a few million characters.
I don't know Hibernate well enough to propose a fix but "where in" with Hibernate is an absolute no-go as it is right now.
We had switch all our "where in" queries to native :-(
--
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-678) @NumericField does not work with BigDecimal types (and others?)
by Nick Fenwick (JIRA)
@NumericField does not work with BigDecimal types (and others?)
---------------------------------------------------------------
Key: HSEARCH-678
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-678
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.3.0.Final
Environment: Hibernate 3.6.0, MySQL 5.1.52, Fedora Core 14
Reporter: Nick Fenwick
This is my first JIRA so please help me assigns its Component above correctly.
My first attempt to use BigDecimal ran into trouble trying to use the new @NumericField annotation. The SessionFactory fails to create an instance of the session. The code:
{{
@Column(name="val")
@Field(name="val", index=Index.UN_TOKENIZED, store=Store.YES)
@NumericField
private BigDecimal val;
}}
Results in the exception:
{{
Exception in thread "main" java.lang.ExceptionInInitializerError
[cut]
Caused by: org.hibernate.HibernateException: could not init listeners
[cut]
Caused by: org.hibernate.search.SearchException: Unable to guess FieldBridge for val
at org.hibernate.search.bridge.BridgeFactory.guessType(BridgeFactory.java:250)
at org.hibernate.search.engine.AbstractDocumentBuilder.bindFieldAnnotation(AbstractDocumentBuilder.java:690)
at org.hibernate.search.engine.AbstractDocumentBuilder.checkForField(AbstractDocumentBuilder.java:564)
[cut]
}}
Taking out the @NumericField allows the session to start up successfully.
I will attempt to make a test case but I'm having local build env issues. 'mvn clean install' of a fresh hibernate search git checkout is taking an incredibly long time (an hour for the first 10 or so .pom files?) so I may be several hours or days over this trivial task.
--
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-992) DB matrix test org.hibernate.search.test.bridge.BridgeTest fails against Sybase
by Hardy Ferentschik (JIRA)
DB matrix test org.hibernate.search.test.bridge.BridgeTest fails against Sybase
-------------------------------------------------------------------------------
Key: HSEARCH-992
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-992
Project: Hibernate Search
Issue Type: Bug
Components: tests
Affects Versions: 4.0.0.CR2
Reporter: Hardy Ferentschik
Assignee: Hardy Ferentschik
Fix For: 4.0.0.Final
The exception is:
{noformat}
org.hibernate.exception.SQLGrammarException: DB2 SQL Error: SQLCODE=-204, SQLSTATE=42704, SQLERRMC=DBALLO02.CLOUD, DRIVER=4.11.77
at org.hibernate.exception.internal.SQLStateConverter.convert(SQLStateConverter.java:100)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81)
{noformat}
Trying to look up the error code seems to indicate that there is an unsupported column type. Looking at the log I can see:
{noformat}
12:20:10,716 (main) ERROR SchemaExport:426 - HHH000389: Unsuccessful: create table Cloud (id integer generated by default as identity, calendarDay timestamp, calendarHour timestamp, calendarMillisecond timestamp, calendarMinute timestamp, calendarMonth timestamp, calendarSecond timestamp, calendarYear timestamp, char1 char(1), char2 char(1) not null, clazz varchar(255), customFieldBridge varchar(255), customStringBridge varchar(255), dateDay timestamp, dateHour timestamp, dateMillisecond timestamp, dateMinute timestamp, dateMonth timestamp, dateSecond timestamp, dateYear timestamp, double1 double, double2 double not null, float1 float, float2 float not null, integerv1 integer, integerv2 integer not null, long1 bigint, long2 bigint not null, myCalendar timestamp, myDate timestamp, storm smallint not null, string varchar(255), type integer, uri varchar(255) for bit data, url varchar(255), uuid char(255) for bit data, primary key (id))
12:20:10,717 (main) ERROR SchemaExport:427 - DB2 SQL Error: SQLCODE=-604, SQLSTATE=42611, SQLERRMC=char(255), DRIVER=4.11.77
{noformat}
It seems the problem is _uuid char(255)_ where _char_ is not a valid data type. _UUID_ does not have any specific mapping confirmation in the test class _Cload_. I cannot find a mapping in the _Dialect_ class either. Almost seems like a Hibernate Core issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-6844) One-To-One fails to delete both sides if constraint violation occurs
by Jana (JIRA)
One-To-One fails to delete both sides if constraint violation occurs
--------------------------------------------------------------------
Key: HHH-6844
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6844
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.8
Environment: Using hibernate version 3.6.8 on a mac OS 10.x.
Reporter: Jana
In this example there are two object: User and Credentials and they have a unidirectional one-to-one relationship. If User fails to persist due to a constraint violation on the emailAddress field, then the Credentials are saved but not removed when the exception is thrown. So now in the database there is no User object but there is a Credentials object. I have set the cascade type to ALL so my expectations would be if an error occurs during persisting the User that neither object remains in the database. As a workaround I go and check for orphans. I've tried a bi-directional one-to-one to see if that made any difference but it also failed to cleanup after the exception.
Below is the code. I left out the setters/getters to condense the code. I know the orphanRemoval=true is redundant since I have cascadeType=ALL but was trying different ways to force the orphan to be removed so left it there in this example.
To test:
public class Test {
public void testPersist() {
User user = new User();
Credentials credentials = new Credentials();
credentials.setUsername("username");
credentials.setPassword("password");
user.setCredentials(credentials);
user.setEmailAddress("myemail(a)wherever.com");
user.persist(); // this will persist as expected.
User user2 = new User();
Credentials credentials2 = new Credentials();
credentials2.setUsername("username2");
credentials2.setPassword("password");
user2.setCredentials(credentials2);
user2.setEmailAddress("myemail(a)wherever.com"); // same email address so will cause a constraint violation
user2.persist(); // this will throw a constraint violation. User2 won't be persisted but credentials will leaving an orphan
}
}
public class User {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "id")
private Long id;
@NotNull
@Column(unique = true)
@Size(min = 1)
private String emailAddress;
@OneToOne(targetEntity=Credentials.class, cascade=CascadeType.ALL, fetch=FetchType.LAZY, orphanRemoval=true)
private Credentials credentials;
}
public class Credentials {
@NotNull
@Column(unique = true)
@Size(min = 1, max=255)
private String username;
@NotNull
@Size(min = 1, max=255)
private String password;
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-5409) bag and idbag should implement equals() and hashCode() the same way as other collections
by Dmitry Katsubo (JIRA)
bag and idbag should implement equals() and hashCode() the same way as other collections
----------------------------------------------------------------------------------------
Key: HHH-5409
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5409
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Dmitry Katsubo
bags/idbags behave in inconsistent way in comparison to set/list/map in respect to {{equals()}} and {{hashCode()}}.
In {{[PersistentBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentBag.java?r=HEAD#l510]}} {{equals()}} and {{hashCode()}} methods are commented and in {{[PersistentIdentifierBag.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentIdentifierBag.java?r=HEAD]}} not present.
{{[PersistentMap.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentMap.java?r=HEAD#l449]}}, {{[PersistentSet.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentSet.java?r=HEAD#l428]}}, {{[PersistentList.java|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/PersistentList.java?r=HEAD#l484]}} however implement {{equals()}} and {{hashCode()}} methods correctly.
The intention of this is clear: to avoid loading of the lazy collection on simple {{equals()}} call.
* I think that it is a task for the end application to handle lazy collections as it is aware about this situation.
* If there is a strong demand of not loading collections on {{equals()}} call for some applications, I suggest to make this behaviour configurable via additional attribute in XML mapping for all collections.
* The behaviour should be documented as suggested in HHH-1642. I personally spend hours debugging before I understood why lists behave differently from bags.
Probably relative issues:
* HHH-3771 ({{equals()}} for lazy loaded objects)
* HHH-1642 ({{equals()}} for {{[AbstractPersistentCollection.SetProxy|http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/collection/AbstractPersistentCollection.java?r=HEAD#l636]}})
--
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