6:26 p.m.
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate3
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to only
add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
6 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Ian Springer commented on HHH-3028:
-----------------------------------
Here's a link to the related hibernate-dev thread:
http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg02463.html
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate3
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
1:29 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Jesus Salvo commented on HHH-3028:
----------------------------------
We just hit this bug, and it seems to be existing since as far back as Hibernate core
3.1.3 ( What we have been using ... but will upgrade soon to the latest release ).
Like what the reporter said, this happens when you have a lot of DML operations before
committing or rolling back. We are using Hibernate also against an Oracle temporary table
as a "working table" before the final data is "transferred" to the
actual table. We cannot commit or rollback on that session, because when you do, you lose
the contents of the temporary table. Thus, the contents of ActionQueue.executions
continually builds up. It was not noticable because more often that not, the contents of
the "working table" is only small ( e.g. a few rows ) but we suddenly have cases
where the contents of the "working table" is now large.
We will try turning off query cache on this session and see if that helps.
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
6:34 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Jesus Salvo commented on HHH-3028:
----------------------------------
Sorry ... I meant that the contents of ActionQueue.executions is now large because there
are a lot more "edits" on the "working table".
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
2:09 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
rajesh kumar commented on HHH-3028:
-----------------------------------
This is one of the major issue which is affecting the hibernate performance. Is any
solution avilable to this problem in the latest release
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
4:23 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Shawn Clowater commented on HHH-3028:
-------------------------------------
I think this may be addressed by the fact that at some point the query cache handling was
changed.
In Hibernate 3.5.2 (not sure what the earliest appearance is) but the ActionQueue now only
keeps track of the query spaces to invalidate and not the complete collection of actions.
{code}
if ( session.getFactory().getSettings().isQueryCacheEnabled() ) {
final String[] spaces = (String[]) executable.getPropertySpaces();
afterTransactionProcesses.addSpacesToInvalidate( spaces );
session.getFactory().getUpdateTimestampsCache().preinvalidate(
executable.getPropertySpaces() );
}
{code}
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
6:26 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Strong Liu commented on HHH-3028:
---------------------------------
iirc, this is resolved (i don't know when), take a look of
https://github.com/hibernate/hibernate-core/blob/master/hibernate-core/sr...,
the ActionQuene does not hold reference anymore.
would you guys please confirm? (or am i missing anythign here?)
p.s. i just tried insert Integer.MAX_VALUE simple objects with query cache enabled, and no
OME
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
1:06 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Markus Heiden commented on HHH-3028:
------------------------------------
The ArrayList "executions" is gone, but it seems, that it has been replaced by
AfterTransactionCompletionProcessQueue "afterTransactionProcesses" and
BeforeTransactionCompletionProcessQueue "beforeTransactionProcesses". I cannot
verify, if the problem is gone, because I have no access to the program anymore in which
the problem occured.
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
3:20 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Shawn Clowater commented on HHH-3028:
-------------------------------------
I'm 99% sure this issue is fixed in regards to the query cache.
There's a separate JIRA floating around with the same type of issue if you happen to
have a postCommitListener enabled as all actions are captured by the fact that the
needsAfterTransactionCompletion() simply checks to see if there are any post commit
listeners (or if the persister declares the entity cached)
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
3:33 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Tim Downey commented on HHH-3028:
---------------------------------
I was the one who opened the other issue with the patch. I was actually looking at it
this week since we're trying to update to the newest Hibernate and I agree that the
issue seems to have been fixed. The fix isn't the same as the patch I added in
HHH-3495 as some things have changed in the cache SPI, but it seems to provide the same
benefit.
I expect to be able to confirm this for sure some time in the next week or so when I run
some regression tests of my app against our bulk data. It will be apparent when I run
against our bulk data since it will end up requiring more memory than I have. ;)
I'll comment again once I've verified things experimentally.
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
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
7 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Gail Badner commented on HHH-3028:
----------------------------------
Tim, were you able to verify this issue is fixed?
Thanks,
Gail
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Tim Downey commented on HHH-3028:
---------------------------------
Gail,
Yes. It appears to be fixed. I apologize for not responding sooner.
Regards,
Tim
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:58 p.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-3028) Memory consumption when query cache is enabled
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=c...
]
Gail Badner resolved HHH-3028.
------------------------------
Resolution: Cannot Reproduce
Assignee: Gail Badner
Tim, thanks for letting us know.
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
Assignee: Gail Badner
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug
describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache =
session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added
to "executions", the related entity which is referenced from the
"executable" is prevented from being garbage collected until the transaction
ends. So if one needs to insert large amounts of transient objects in one transaction,
there is no chance to get rid of the inserted objects by flushing and evicting them, if
e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to
only add objects to "executions" if this is really needed. The problem is to
determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field
"instance" in EntityAction) to null after flushing. This does not prevent
"executions" from being filled, but the related entities might be garbage
collected and so the memory consumption is acceptable. The problem is that subclasses of
EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful
feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks
transactional safety.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4883
days inactive
6209
days old
hibernate-issues@lists.jboss.org
12 comments
8 participants
participants (8)
-
Gail Badner (JIRA) -
Ian Springer (JIRA)
-
Jesus Salvo (JIRA)
-
Markus Heiden (JIRA)
-
rajesh kumar (JIRA)
-
Shawn Clowater (JIRA)
-
Strong Liu (JIRA)
-
Tim Downey (JIRA)