April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-328) Async store to support frequency based flushing

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-328?page=com.atlassian.jira.plugin.s... ] Prashant Thakur commented on ISPN-328: -------------------------------------- Can we control that writes to DB is done only through one of instances and that instance might be chosen by cluster elements. > Async store to support frequency based flushing > ----------------------------------------------- > > Key: ISPN-328 > URL: https://issues.jboss.org/browse/ISPN-328 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: hackathon > > Implement frequency based flushing in the async store. This is also called, Scheduled Write-Behing Strategy. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4229) The JDBC Cache store should not require the schema name configuration

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4229?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4229: ------------------------------------ Yes, I was thinking whether backporting ISPN-3006 would have been simpler, considering that ISPN-3006 was already validated on various databases. But I was also considering whether we need to restore your fix on master, as I wasn't sure the fact that the ISPN-3006 fix looks in the current user's schema on Oracle is ok. We can't control how the user sets up his JDBC data source, so I guess the should really go back to your version. > The JDBC Cache store should not require the schema name configuration > --------------------------------------------------------------------- > > Key: ISPN-4229 > URL: https://issues.jboss.org/browse/ISPN-4229 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-3908) Security (Authentication, Authorization, Audit, Encryption)

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3908?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3908: ---------------------------------- Summary: Security (Authentication, Authorization, Audit, Encryption) (was: Security (Authentication, Authorization, Encryption)) > Security (Authentication, Authorization, Audit, Encryption) > ----------------------------------------------------------- > > Key: ISPN-3908 > URL: https://issues.jboss.org/browse/ISPN-3908 > Project: Infinispan > Issue Type: Task > Components: Core, Remote Protocols, Security, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Labels: roadmap > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4245) ConsistentHashFactory needs to be configurable via XML

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4245: -------------------------------------- Summary: ConsistentHashFactory needs to be configurable via XML Key: ISPN-4245 URL: https://issues.jboss.org/browse/ISPN-4245 Project: Infinispan Issue Type: Enhancement Components: Configuration Affects Versions: 7.0.0.Alpha3 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Alpha4 In the XML parsing changes added in ISPN-3514, I forgot to add ConsistentHashFactory configuration. This is needed in order to be able to have multiple caches with the same consistent hash. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Lock container ignores key Equivalence

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4207: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Lock container ignores key Equivalence > -------------------------------------- > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. > edit: the Stripped*LockContainer suffers from the same problem since it uses object.hashCode(). -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4229) The JDBC Cache store should not require the schema name configuration

by Nicolas Filotto (JIRA)

[ https://issues.jboss.org/browse/ISPN-4229?page=com.atlassian.jira.plugin.... ] Nicolas Filotto edited comment on ISPN-4229 at 4/28/14 8:10 AM: ---------------------------------------------------------------- If the question is: "Would it be enough to back port the fix for ISPN-3006?" I would say that I need to test on all supported dbs but I think that it could be enough if and only if we don't change the current default schema in the datasource configuration. For example on db like DB2, you can also use the same database and simply change the current default schema thanks to jdbc url of type jdbc:db2://MYHOST:MYPORT/MYDB:currentSchema=MYSCHEMA; On oracle it is also possible but it is a little bit more tricky https://community.oracle.com/thread/1038211?start=0&tstart=0 was (Author: nfilotto): If the question is: "Would it be enough to back port the fix for ISPN-3006?" I would say that I need to test on all supported dbs but I think that it could be enough if and only if we don't change the current default schema in the datasource configuration. For example on db like DB2, you can also use the same database and simply change the current default schema thanks to jdbc url of type jdbc:db2://locahost:50000/MYDB:currentSchema=OLYMPIA; On oracle it is also possible but it is a little bit more tricky https://community.oracle.com/thread/1038211?start=0&tstart=0 > The JDBC Cache store should not require the schema name configuration > --------------------------------------------------------------------- > > Key: ISPN-4229 > URL: https://issues.jboss.org/browse/ISPN-4229 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4229) The JDBC Cache store should not require the schema name configuration

by Nicolas Filotto (JIRA)

[ https://issues.jboss.org/browse/ISPN-4229?page=com.atlassian.jira.plugin.... ] Nicolas Filotto commented on ISPN-4229: --------------------------------------- If the question is: "Would it be enough to back port the fix for ISPN-3006?" I would say that I need to test on all supported dbs but I think that it could be enough if and only if we don't change the current default schema in the datasource configuration. For example on db like DB2, you can also use the same database and simply change the current default schema thanks to jdbc url of type jdbc:db2://locahost:50000/MYDB:currentSchema=OLYMPIA; On oracle it is also possible but it is a little bit more tricky https://community.oracle.com/thread/1038211?start=0&tstart=0 > The JDBC Cache store should not require the schema name configuration > --------------------------------------------------------------------- > > Key: ISPN-4229 > URL: https://issues.jboss.org/browse/ISPN-4229 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > -- 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

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3953: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1091901|https://bugzilla.redhat.com/show_bug.cgi?id=1091901] from NEW to CLOSED > 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 > Labels: 630 > Fix For: 7.0.0.Alpha3 > > > 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

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4061) JPA Cache Store fails on Oracle, Postgres and MsSQL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4061?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4061: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1091901|https://bugzilla.redhat.com/show_bug.cgi?id=1091901] from NEW to CLOSED > JPA Cache Store fails on Oracle, Postgres and MsSQL > --------------------------------------------------- > > Key: ISPN-4061 > URL: https://issues.jboss.org/browse/ISPN-4061 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > Current snapshot version of JPA Cache Store fails on Oracle (see [failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...] with stack traces), Postgres ([failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...]) and MsSQL ([failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...]). > While in case of Oracle and Postgres the problem is probably in {{\_\_ispn_metadata\_\_}} table, in case of MsSQL problem is in "User" entity, as User is reserved name in MsSQL. Oracle has a problem with table starting with underscrore, in case of Postgres {{VARBINARY}} type used in {{\_\_ispn_metadata\_\_}} is not available in. In case of MsSQL I'm not completely sure if it's bug or if it should be handled by user. -- 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

1
0
0 / 0

[JBoss JIRA] (ISPN-4072) JPA Cache Store fails to clear entity which contains ElementCollection

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4072?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4072: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1091901|https://bugzilla.redhat.com/show_bug.cgi?id=1091901] from NEW to CLOSED > JPA Cache Store fails to clear entity which contains ElementCollection > ---------------------------------------------------------------------- > > Key: ISPN-4072 > URL: https://issues.jboss.org/browse/ISPN-4072 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > When entity stored by JPA Cache Store contains [ElementCollection|http://docs.oracle.com/javaee/6/api/javax/persistence/E...], {{clear()}} operation fails with foreign key constraint violation. > Stack trace in case of MySQL: > {noformat} > org.infinispan.persistence.jpa.JpaStoreException: Exception caught in clear() > at org.infinispan.persistence.jpa.JpaStore.clear(JpaStore.java:143) > at org.infinispan.persistence.jpa.BaseJpaStoreTest.setUp(BaseJpaStoreTest.java:85) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement > at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) > at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) > at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:1397) > at org.hibernate.ejb.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:108) > at org.infinispan.persistence.jpa.JpaStore.clear(JpaStore.java:128) > ... 23 more > Caused by: org.hibernate.exception.ConstraintViolationException: could not execute statement > at org.hibernate.exception.internal.SQLExceptionTypeDelegate.convert(SQLExceptionTypeDelegate.java:74) > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) > at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:136) > at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(BasicExecutor.java:103) > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:413) > at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:282) > at org.hibernate.internal.SessionImpl.executeUpdate(SessionImpl.java:1290) > at org.hibernate.internal.QueryImpl.executeUpdate(QueryImpl.java:116) > at org.hibernate.ejb.QueryImpl.internalExecuteUpdate(QueryImpl.java:194) > at org.hibernate.ejb.AbstractQueryImpl.executeUpdate(AbstractQueryImpl.java:99) > ... 24 more > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot delete or update a parent row: a foreign key constraint fails (`ispn_jpa_test`.`Person_nickNames`, CONSTRAINT `FK_ne1r4l90nve6426b7c7ws198i` FOREIGN KEY (`Person_id`) REFERENCES `Person` (`id`)) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1039) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2677) > at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2134) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2434) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2352) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2337) > at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:133) > ... 31 more > {noformat} -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2014