January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3953) JPACacheStore should not load all entities in memory

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3953: -------------------------------- Assignee: Radim Vansa (was: Mircea Markus) > JPACacheStore should not load all entities in memory > ---------------------------------------------------- > > Key: ISPN-3953 > URL: https://issues.jboss.org/browse/ISPN-3953 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Emmanuel Bernard > Assignee: Radim Vansa > > Today several methods use getResultList() and load either all keys or all entities for a given entity type in- memory at the same time. > This will likely blow up for big tables. > There are two solutions: > ## Use Hibernate's specific features > Hibernate ORM has a session.scroll() method that offers a FORWARD_ONLY scrollable result set. You can then load data and regularly (every 100?) clear the session before hitting the next result. This will diminish greatly the memory pressure. > ## Use a window model > get the number of entities in the table select count(*) > Then use setFirstResult / setMaxResults to navigate the data with a sliding window and clear the session every time you move the window. > This won't be as efficient as Hibernate ORM's specific approach but will do the work except on database that don't support the ability to start the results at the nth element. Look up Hibernate dialects for more info. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3954) Use Hibernate's StatelessSession for the JPACacheStore

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3954?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3954: -------------------------------- Assignee: Radim Vansa (was: Mircea Markus) > Use Hibernate's StatelessSession for the JPACacheStore > ------------------------------------------------------ > > Key: ISPN-3954 > URL: https://issues.jboss.org/browse/ISPN-3954 > Project: Infinispan > Issue Type: Enhancement > Reporter: Emmanuel Bernard > Assignee: Radim Vansa > > The current model uses the regular session even though operations are tailored toward actions (insert, update, delete). > It would be better to make use of the Hibernate StatelessSession API which has been designed for these use cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3954) Use Hibernate's StatelessSession for the JPACacheStore

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3954?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3954: -------------------------------- Component/s: Loaders and Stores > Use Hibernate's StatelessSession for the JPACacheStore > ------------------------------------------------------ > > Key: ISPN-3954 > URL: https://issues.jboss.org/browse/ISPN-3954 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Emmanuel Bernard > Assignee: Radim Vansa > > The current model uses the regular session even though operations are tailored toward actions (insert, update, delete). > It would be better to make use of the Hibernate StatelessSession API which has been designed for these use cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3957: -------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/2362, https://github.com/infinispan/infinispan/pull/2364 (was: https://github.com/infinispan/infinispan/pull/2362) > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3957: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2362 > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3957: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059489 > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3957: ----------------------------------- Summary: Preload with async cache store is not efficient Key: ISPN-3957 URL: https://issues.jboss.org/browse/ISPN-3957 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 5.2.7.Final Reporter: Mircea Markus Assignee: Dan Berindei Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3956: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2361 > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3956: -------------------------------- Description: This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. was: This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 The issue is that we don't set the remove lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] Work on ISPN-3956 started by William Burns. > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remove lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014