[Hibernate-JIRA] Created: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query
by Piotr Kołaczkowski (JIRA)
FlushMode.AUTO practically unusable - should not flush before EVERY query
-------------------------------------------------------------------------
Key: HHH-2399
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399
Project: Hibernate3
Type: Improvement
Versions: 3.1.3, 3.2.1, 3.2.2, 3.2.0.ga
Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09
Reporter: Piotr Kołaczkowski
Attachments: hbtest.zip
The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment):
- database level: 0.05 ms
- pure JDBC code, prepared statements: 0.2 ms
- pure JDBC code, no prepared statements: 0.7 ms
- not cached hibernate query, no other objects associated with the session: 1.3 ms
- cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms
- cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms
10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better.
Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED.
BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong?
There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms.
--
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-4741) rg.hibernate.test.filter.DynamicFilterTest.testSqlSyntaxOfFiltersWithUnions
by Strong Liu (JIRA)
rg.hibernate.test.filter.DynamicFilterTest.testSqlSyntaxOfFiltersWithUnions
---------------------------------------------------------------------------
Key: HHH-4741
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4741
Project: Hibernate Core
Issue Type: Bug
Components: testsuite
Affects Versions: 3.5.0.Beta-1, 3.3.2
Environment: MySQL
Reporter: Strong Liu
Assignee: Strong Liu
Priority: Minor
Fix For: 3.3.x, 3.5
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.doList(Loader.java:2235)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
at org.hibernate.loader.Loader.list(Loader.java:2124)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1149)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.hibernate.test.filter.DynamicFilterTest.testSqlSyntaxOfFiltersWithUnions(DynamicFilterTest.java:76)
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Table 'hibbr330.department' doesn't exist
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2941)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3249)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1268)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1403)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1812)
at org.hibernate.loader.Loader.doQuery(Loader.java:697)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2232)
... 37 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, 6 months
[Hibernate-JIRA] Commented: (HHH-1123) Cannot put more than 1000 elements in a InExpression
by Strong Liu (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ]
Strong Liu commented on HHH-1123:
---------------------------------
The maximum on ms sql server is 2100
> Cannot put more than 1000 elements in a InExpression
> ----------------------------------------------------
>
> Key: HHH-1123
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 rc2, 3.2.0.alpha1
> Environment: Oracle 9i
> Reporter: Alexis Seigneurin
> Assignee: Strong Liu
> Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, LongInElementsTest.java, patch.txt
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones.
> Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be :
> (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?))
> The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions).
--
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-4531) Derby dialect should not support comments
by Chris Wilson (JIRA)
Derby dialect should not support comments
-----------------------------------------
Key: HHH-4531
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4531
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: Derby 10.5.3.0, Linux
Reporter: Chris Wilson
Our mapping files contain column comments because they are supported on some of our databases. We use hbm2ddl to export the schema to each database. We are now adding support for Derby.
Unfortunately Derby does not support column comments. I get errors like:
ERROR SchemaExport: Unsuccessful: comment on column building_type.description is 'Site Building Type Description'
ERROR SchemaExport: Syntax error: Encountered "comment" at line 1, column 1.
I think that the DerbyDialect should return false for supportsCommentOn(). However it inherits from DB2Dialect which returns true for this property.
Please add the following to DerbyDialect:
public boolean supportsCommentOn() {
return false;
}
--
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] Resolved: (HHH-1918) enable non-hilo identity generation in DerbyDialect
by Strong Liu (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1918?page=c... ]
Strong Liu resolved HHH-1918.
-----------------------------
Resolution: Fixed
Fix Version/s: 3.5
> enable non-hilo identity generation in DerbyDialect
> ---------------------------------------------------
>
> Key: HHH-1918
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1918
> Project: Hibernate Core
> Issue Type: Patch
> Environment: 3.2.0.rc2, Derby
> Reporter: Adrian Moos
> Priority: Minor
> Fix For: 3.5
>
> Original Estimate: 2 minutes
> Remaining Estimate: 2 minutes
>
> > From: hibernate-devel-bounces(a)lists.sourceforge.net
> > [mailto:hibernate-devel-bounces@lists.sourceforge.net]On Behalf Of Max
> > Rydahl Andersen
> > Sent: Mittwoch, 12. Juli 2006 12:20
> > To: hibernate-devel(a)lists.sourceforge.net
> > Cc: skjohn(a)us.ibm.com
> > Subject: Re: [Hibernate] native id generation in DerbyDialect
> >
> >
> > The DerbyDialect was contributed by an external party.
> >
> > If you have a better implementation patches are welcome in our jira.
> See below. Knowing little about derby I am not sure 100% sure it is better, but it appears to be.
> > But it would be nice to know why the external contributor choose
> > to use tablehilo as the default and have that "fun"
> > identitycolumnstring.
> Indeed. Alas, he hasn't replied ...
> Patch: Delete
> public Class getNativeIdentifierGeneratorClass() {
> return TableHiLoGenerator.class;
> }
> from org.hibernate.dialect.DerbyDialect
> QA: My test application using sequence identifier generation works correctly. Identity generation not tested, but as the contributor provided an improved query string this should be ok.
--
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-2347) Improvement to DerbyDialect default identy generation mode
by Fabrizio Giustina (JIRA)
Improvement to DerbyDialect default identy generation mode
----------------------------------------------------------
Key: HHH-2347
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2347
Project: Hibernate3
Type: Patch
Versions: 3.2.1
Reporter: Fabrizio Giustina
Attachments: DerbyDialect-identity.diff
although derby supports identities org.hibernate.dialect.DerbyDialect strangely uses an HiLo generation strategy for ids (for any other dialects that support identities IdentityGenerator is the default).
Even more curiously, DerbyDialect overrides getIdentityColumnString() from the Db2 dialect by using "generated ALWAYS as identity" instead of "generated BY DEFAULT as identity". Derby however fully supports "by default" in identities as clarified in http://db.apache.org/derby/docs/10.1/ref/rrefsqlj37836.html .
"by default" should be preferred since it allows a direct insertion when needed (and I can't see no reason why enabling it for db2 and not for derby).
The patch attached simply deletes two methods, so that the default implementation from Db2Dialect is used:
- removing getIdentityColumnString() make derby use "by default" identities like db2 already does
- removing getNativeIdentifierGeneratorClass() make it choose IdentityGenerator.class (it falls back to the default strategy used in org.hibernate.dialect.Dialect)
note that part of this issue has already been reported in HHH-1918 (not addressing the identity generation string)
--
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-4574) ConnectionProviderFactory.getConnectionProperties() includes extra properties
by Kevin Bowman (JIRA)
ConnectionProviderFactory.getConnectionProperties() includes extra properties
------------------------------------------------------------------------------
Key: HHH-4574
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4574
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4.sp1, Derby DB.
Any Java environment where System properties include many properties whose names *include* 'hibernate.connection' but do not *start with* 'hibernate.connection'.
Reporter: Kevin Bowman
Attachments: org.hibernate.connection.ConnectionProviderFactory.patch, PropertiesTest.java
In our environment we are setting a number of properties with keys like 'rpt.3.hibernate.connection.url'. They are used indirectly for configuring hibernate, but only a small fraction of them are used for configuring any given hibernate session. Unfortunately, all these System properties are being pulled into JDBC URL because of ConnectionProviderFactory, which causes problems like this with DerbyDB:
2009-11-13 09:57:19,065 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@67f2b0dd -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception:
java.sql.SQLTransientConnectionException: A connection could not be established because the database name 'reports/lisa-reports.db;ction.password_enc=76f271db3661fd50082e68d4b953fbee;ction.username=sa;autocommit=false;ion.url=internal;create=true;ction.url=jdbc:derby://localhost:1527/db/reports.db;ction.driver_class=org.apache.derby.jdbc.ClientDriver' is larger than the maximum length allowed by the network protocol.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182)
at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137)
at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014)
at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32)
at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810)
at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
Caused by: org.apache.derby.client.am.SqlException: A connection could not be established because the database name 'reports/lisa-reports.db;ction.password_enc=76f271db3661fd50082e68d4b953fbee;ction.username=sa;autocommit=false;ion.url=internal;create=true;ction.url=jdbc:derby://localhost:1527/db/reports.db;ction.driver_class=org.apache.derby.jdbc.ClientDriver' is larger than the maximum length allowed by the network protocol.
at org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source)
at org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source)
at org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown Source)
at org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source)
... 9 more
Attached is a test case and patch.
--
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