[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Affects Version/s: 10.13.1.1
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Description:
After a few days of working with an embedded Derby database (currently version
10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this {{OutOfMemoryError}}. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
clearly a Derby bug.
was:
After a few days of working with an embedded Derby database (currently version
10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Description:
After a few days of working with an embedded Derby database (currently version
10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this {{OutOfMemoryError}}. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
clearly a Derby bug.
was:
After a few days of working with an embedded Derby database (currently version
10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Description:
After a few days of working with an embedded Derby database (currently version
10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this OutOfMemoryException. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
clearly a Derby bug.
was:
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Description:
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this OutOfMemoryException. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
clearly a Derby bug.
was:
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco updated DERBY-7049:
-
Description:
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this OutOfMemoryException. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
clearly a Derby bug.
was:
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
[jira] [Created] (DERBY-7049) OutOfMemoryError: Compressed class space
Marco created DERBY-7049:
Summary: OutOfMemoryError: Compressed class space
Key: DERBY-7049
URL: https://issues.apache.org/jira/browse/DERBY-7049
Project: Derby
Issue Type: Bug
Reporter: Marco
After a few days of working with an embedded Derby database (currently version
10.13.1.1), the following error occurs:
*java.lang.OutOfMemoryError: Compressed class space*
{code:java}
java.lang.OutOfMemoryError: Compressed class space
at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
at
org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
~[derby-10.13.1.1.jar:na]
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown Source)
~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
Source) ~[derby-10.13.1.1.jar:na]
at
org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
~[datanucleus-rdbms-4.0.12.jar:na]{code}
I tried to solve the problem by periodically shutting down the database,
because I read that the generated classes as well as all other allocated
resources should be released when the DB is shut-down.
I thus perform the following code once per roughly 20 minutes:
{code:java}
String shutdownConnectionURL = connectionURL + ";shutdown=true";
try {
DriverManager.getConnection(shutdownConnectionURL);
} catch (SQLException e) {
int errorCode = e.getErrorCode();
if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
throw new RuntimeException(e);
}
}
{code}
Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
about 2 days. Do I assume correctly that the above code _should_ properly
shut-down the database? And do I assume correctly that this shut-down should
release the generated classes?
IMHO, it is already a bug in Derby that I need to shut-down the database at all
in order to prevent it from piling up generated classes. Shouldn't it already
release the generated classes at the end of each transaction? But even if I
really have to shut-down the DB, it is certainly a bug that the classes are
still kept in "compressed class space" even after the shut-down.
I searched the release notes and the existing bugs (here in JIRA) and did not
find anything related to this OutOfMemoryException. Hence, I open this
bug-report, now.
This issue was originally reported in
[subshare#74|[https://github.com/subshare/subshare/issues/74],] but it is IMHO
clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890625#comment-16890625 ] Bernard edited comment on DERBY-5728 at 7/23/19 2:48 AM: - >From what I can remember, it goes like this: Imagine we have a client form with multiple field entries, each tied to a JPQL fragment for that field. Let's start with one field: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName Then take two fields: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName and :firstName IS NULL OR a.firstName = :firstName If we can do this, then effectively the database ensures that, if an entry is missing, that the corresponding fragment can be ignored because it returns true. This is how programmers want the computer to behave. If we can't do this, and this issue prevents this from working, then things get really complicated. It does not work because the DB cannot handle NULL IS NULL where the first NULL is the missing parameter from the form. was (Author: bht): >From what I can remember, it goes like this: Imagine we have a client form with multiple field entries, each tied to a JPQL fragment for that field. Let's start with one field: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName Then take two fields: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName and :firstName IS NULL OR a.firstName = :firstName If we can do this, then effectively the database ensures that, if an entry is missing, that the corresponding fragment can be ignored because it returns true. This is how programmers want the computer to behave. If we can't do this, and this issue prevents this from working, then things get really complicated. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890625#comment-16890625 ] Bernard edited comment on DERBY-5728 at 7/23/19 2:45 AM: - >From what I can remember, it goes like this: Imagine we have a client form with multiple field entries, each tied to a JPQL fragment for that field. Let's start with one field: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName Then take two fields: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName and :firstName IS NULL OR a.firstName = :firstName If we can do this, then effectively the database ensures that, if an entry is missing, that the corresponding fragment can be ignored because it returns true. This is how programmers want the computer to behave. If we can't do this, and this issue prevents this from working, then things get really complicated. was (Author: bht): >From what I can remember, it goes like this: Imagine we have a client form with multiple field entries, each tied to a JPQL fragment for that field. Let's start with one field: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName Then take two fields: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName and :firstName IS NULL OR a.firstName = :firstName If we can do this, then effectively the database ensures that, if an entry is missing, that the corresponding fragment can be ignored because it returns true. This is how programmers want the computer to behave. If we can't do this, and this issue prevents this from working, then things get really complicated in comparison. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890625#comment-16890625 ] Bernard commented on DERBY-5728: >From what I can remember, it goes like this: Imagine we have a client form with multiple field entries, each tied to a JPQL fragment for that field. Let's start with one field: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName Then take two fields: SELECT a FROM Author a WHERE :lastName IS NULL OR a.lastName = :lastName and :firstName IS NULL OR a.firstName = :firstName If we can do this, then effectively the database ensures that, if an entry is missing, that the corresponding fragment can be ignored because it returns true. This is how programmers want the computer to behave. If we can't do this, and this issue prevents this from working, then things get really complicated in comparison. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890576#comment-16890576 ] Rick Hillegas commented on DERBY-5728: -- Hi Bernard. Can you help me understand what the JPQL query is trying to achieve? What does it mean? Thanks. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890532#comment-16890532 ] Bernard commented on DERBY-5728: Hi, I am the original requester. I do not want comment on the illegal statements. But it would be absolutely fantastic if the changes meeting the original request would be implemented. These changes would let us write incredibly powerful and simple JPQL without the cumbersome criteria API. Works with most other databases like SQL Server, Oracle, HSQL, DB2. This is so old but still relevant. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[
https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890522#comment-16890522
]
Rick Hillegas commented on DERBY-5728:
--
Neither of those statements is valid SQL. Did you mean to type the final
statement in the following batch?
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE TABLE vocab (name VARCHAR(50));
-- raises Syntax error: Encountered "NULL" at line 1, column 21.
SELECT * FROM vocab NULL IS NULL;
-- raises Syntax error: Encountered "NULL" at line 1, column 27.
SELECT * FROM vocab WHERE NULL IS NULL;
-- succeeds
SELECT * FROM vocab WHERE name IS NULL;
{noformat}
If not, what are you trying to achieve with those two, illegal statements?
> Add Support for NULL IS NULL
>
>
> Key: DERBY-5728
> URL: https://issues.apache.org/jira/browse/DERBY-5728
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.8.2.2
> Environment: Windows XP
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
>Reporter: bernard
>Priority: Critical
> Labels: derby_triage10_10
> Attachments: NullParameterEclipseLinkDerbyMaven.zip,
> NullParameterHibernateDerbyMaven.zip
>
>
> The following query fails:
> SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL))
> Why this is an issue?
> At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues
> with generating SQL for trivial JPQL queries such as:
> select object(c) from Customer c where ((name: is null) or (c.name = name:))
> where name: is a parameter
> For why this is a fundamental issue, please see a minimalistic JPQL query at
> http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples
> Part of this has already been resolved by issue "Add support for
> setObject(, null)"
> https://issues.apache.org/jira/browse/DERBY-1938
> Please see EclipseLink and Hibernate test cases for verification.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890438#comment-16890438 ] Loc Ha commented on DERBY-5728: --- Please fix this issue. This issue is Not relating to JPA framework. The below query failed (NATIVE Query): SELECT * FROM Vocab NULL IS NULL; /// FAILED // An error occurred when executing the SQL command: SELECT * FROM VOCAB WHERE NULL IS NULL Syntax error: Encountered "NULL" at line 1, column 27. SELECT * FROM VOCAB WHERE NULL IS NULL ^ 1 statement failed. Execution time: 0s > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
