January 2014 - infinispan-issues - Jboss List Archives

[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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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

10 years, 11 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: -------------------------------- Fix Version/s: 7.0.0.Alpha1 7.0.0.Final Assignee: William Burns (was: Mircea Markus) Affects Version/s: 6.0.0.Final Component/s: L1 > 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

10 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014