May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4247) JPA cachestore fails with Oracle12c and PostgreadPlus 9

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4247?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4247: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2544 > JPA cachestore fails with Oracle12c and PostgreadPlus 9 > ------------------------------------------------------- > > Key: ISPN-4247 > URL: https://issues.jboss.org/browse/ISPN-4247 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Vojtech Juranek > Assignee: Dan Berindei > > JPA cache store fails on Oracle12c and PostgreadPlus 9 as Hibernate is not able to determine the dialect to be used: > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > resp. > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=EnterpriseDB, majorVersion=9]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > To fix it, HIbernate upgrade is needed. PotgresPlus is fixed in 4.3.0.Beta4 (tracking JIRA is [HHH-8349|https://hibernate.atlassian.net/browse/HHH-8349]), Oracle12c is fixed in Hibernate 5.0.0 (tracking JIRA is [HHH-9044|https://hibernate.atlassian.net/browse/HHH-9044]) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4270: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1095290|https://bugzilla.redhat.com/show_bug.cgi?id=1095290] from ASSIGNED to MODIFIED > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4270: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2543 > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4270: ------------------------------------- Assignee: Tristan Tarrant (was: Mircea Markus) > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4270: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1095290 > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4270: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1095290|https://bugzilla.redhat.com/show_bug.cgi?id=1095290] from NEW to ASSIGNED > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4270: ------------------------------------- Summary: JPA Cache Store is missing from the BOM Key: ISPN-4270 URL: https://issues.jboss.org/browse/ISPN-4270 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 7.0.0.Alpha3 Reporter: Tristan Tarrant Assignee: Mircea Markus Fix For: 7.0.0.Alpha4, 7.0.0.Final Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-4131 at 5/7/14 6:38 AM: ------------------------------------------------------------ I think I have a possible fix for this: during the completed transactions cleanup, TransactionTable should save the biggest transaction id from each member. When checking if a prepare should be rejected, it should also check the transaction id against the last saved transaction id, and if it's smaller reject it even if it's not in the completed transactions table. It's not even a problem to fail prepare commands because they have been delayed for more than {{SyncConfiguration.replTimeout()}}, so we just have to check during validation that {{TransactionConfiguration.completedTxTimeout()}} is bigger. We just have to make sure we don't do the check for asynchronous caches. was (Author: dan.berindei): I think I have a possible fix for this: during the completed transactions cleanup, TransactionTable should save the biggest transaction id from each member. When checking if a prepare should be rejected, it should also check the transaction id against the next-to-last saved transaction id, and if it's smaller reject it even if it's not in the completed transactions table. It's not even a problem to fail prepare commands because they have been delayed for more than {{SyncConfiguration.replTimeout()}}, so we just have to check during validation that {{TransactionConfiguration.completedTxTimeout()}} is bigger. We just have to make sure we don't do the check for asynchronous caches. > Lock acquired forever with delayed PrepareCommand > ------------------------------------------------- > > Key: ISPN-4131 > URL: https://issues.jboss.org/browse/ISPN-4131 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.2.Final, 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > > Distributed transactional cache: > 1. A sends Prepare to B > 2. B receives Prepare, but due to ongoing ST it is blocked > 3. B replication timeout elapses > 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions. > 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked) > 6. Prepare is executed on B, acquiring lock on K > Nobody will rollback the TX as originator thinks it was already rolled back. > Result: key K will be locked forever, all attempts to update/remove it will fail. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4226) SearchManagerImpl use a bad entity names resolver

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4226?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-4226: ----------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > SearchManagerImpl use a bad entity names resolver > ------------------------------------------------- > > Key: ISPN-4226 > URL: https://issues.jboss.org/browse/ISPN-4226 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 6.0.2.Final > Environment: Wildfly 8.1.0 CR1 > Reporter: David Cabillic > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha4 > > > Inner class org.infinispan.query.impl.SearchManagerImpl$EntityNamesResolver used in method SearchManagerImpl#getQueryFactory use Class.forName(String) instead of Thread.currentThread().getContextClassLoader().loadClass(String) > It is a problem if @Indexed classes are in an EAR/WAR which is not loaded in the same ClassLoader. It works great with ContextClassLoader. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4131: ------------------------------------ I think I have a possible fix for this: during the completed transactions cleanup, TransactionTable should save the biggest transaction id from each member. When checking if a prepare should be rejected, it should also check the transaction id against the next-to-last saved transaction id, and if it's smaller reject it even if it's not in the completed transactions table. It's not even a problem to fail prepare commands because they have been delayed for more than {{SyncConfiguration.replTimeout()}}, so we just have to check during validation that {{TransactionConfiguration.completedTxTimeout()}} is bigger. We just have to make sure we don't do the check for asynchronous caches. > Lock acquired forever with delayed PrepareCommand > ------------------------------------------------- > > Key: ISPN-4131 > URL: https://issues.jboss.org/browse/ISPN-4131 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.2.Final, 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > > Distributed transactional cache: > 1. A sends Prepare to B > 2. B receives Prepare, but due to ongoing ST it is blocked > 3. B replication timeout elapses > 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions. > 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked) > 6. Prepare is executed on B, acquiring lock on K > Nobody will rollback the TX as originator thinks it was already rolled back. > Result: key K will be locked forever, all attempts to update/remove it will fail. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2014