July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1862) fire TransactionCompletedEvent not as part of the transaction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1862?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1862: -------------------------------- Priority: Minor (was: Major) > fire TransactionCompletedEvent not as part of the transaction > ------------------------------------------------------------- > > Key: ISPN-1862 > URL: https://issues.jboss.org/browse/ISPN-1862 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 5.1.1.FINAL > Reporter: Thomas Fromm > Assignee: Manik Surtani > Priority: Minor > > When catching TransactionCompletedEvent I would expect, the transaction is committed, especially when isTransactionSuccessful() == true. > I need to perform some operations after a transaction was completed. My workaround is ATM to suspend the transaction, perform my (async) stuff, and > resume it afterwards. But in case of errors after resume, I get another TransactionCompletedEvent for this transaction with isTransactionSuccessful() == false. > You see, I need something like a TransactionReallyCompletedEvent :-) > My change request is, that the TransactionCompletedEvents should be fired, after the transaction was committed. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1862) fire TransactionCompletedEvent not as part of the transaction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1862?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1862: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > fire TransactionCompletedEvent not as part of the transaction > ------------------------------------------------------------- > > Key: ISPN-1862 > URL: https://issues.jboss.org/browse/ISPN-1862 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 5.1.1.FINAL > Reporter: Thomas Fromm > Assignee: Manik Surtani > > When catching TransactionCompletedEvent I would expect, the transaction is committed, especially when isTransactionSuccessful() == true. > I need to perform some operations after a transaction was completed. My workaround is ATM to suspend the transaction, perform my (async) stuff, and > resume it afterwards. But in case of errors after resume, I get another TransactionCompletedEvent for this transaction with isTransactionSuccessful() == false. > You see, I need something like a TransactionReallyCompletedEvent :-) > My change request is, that the TransactionCompletedEvents should be fired, after the transaction was committed. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-144) graph based deadlock detection

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-144?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-144. -------------------------------- Fix Version/s: (was: 6.0.0.Final) Resolution: Won't Fix total order avoids deadlocks entirely. > graph based deadlock detection > ------------------------------- > > Key: ISPN-144 > URL: https://issues.jboss.org/browse/ISPN-144 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Mircea Markus > > current deadlock detection impl only knows to look for deadlocks between two transactions: i.e. tx1 (k1,k2) tx (k2,k1). This might be enhanced with transitive deadlock detection check: > tx1(k1,k2) tx2(k2,k3) tx3(k3,k1). In the previous example, if all transactions are done acquiring first lock we result in a deadlock. Needs further thinking. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3275) Drop ByteArrayKey

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3275?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3275: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Drop ByteArrayKey > ----------------- > > Key: ISPN-3275 > URL: https://issues.jboss.org/browse/ISPN-3275 > Project: Infinispan > Issue Type: Sub-task > Components: Core API > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1 > > -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3260) Introduce a Commons llibrary of classes to be shared between local and remote implementations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3260?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3260: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Introduce a Commons llibrary of classes to be shared between local and remote implementations > --------------------------------------------------------------------------------------------- > > Key: ISPN-3260 > URL: https://issues.jboss.org/browse/ISPN-3260 > Project: Infinispan > Issue Type: Sub-task > Components: Build process, Core API > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1, 6.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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3259) Introduce a BOM to be shared between Infinispan Library and Server

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3259?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3259: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Introduce a BOM to be shared between Infinispan Library and Server > ------------------------------------------------------------------ > > Key: ISPN-3259 > URL: https://issues.jboss.org/browse/ISPN-3259 > Project: Infinispan > Issue Type: Sub-task > Components: Build process > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha1, 6.0.0.Final > > > Move all core dependency management information to a top-level BOM file and use that to share GAVs between library and server -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2528) Verify and document Query functionality with programmatically defined indexes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2528?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2528: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > Verify and document Query functionality with programmatically defined indexes > ----------------------------------------------------------------------------- > > Key: ISPN-2528 > URL: https://issues.jboss.org/browse/ISPN-2528 > Project: Infinispan > Issue Type: Task > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > > Hibernate Search supports programmatic configuration of indexes, we should add some tests in Infinispan Query to verify the looks of such an API and if it works. > Then document it. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2528) Verify and document Query functionality with programmatically defined indexes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2528?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2528: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > Verify and document Query functionality with programmatically defined indexes > ----------------------------------------------------------------------------- > > Key: ISPN-2528 > URL: https://issues.jboss.org/browse/ISPN-2528 > Project: Infinispan > Issue Type: Task > Components: Querying > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > Labels: stable_embedded_query > Fix For: 6.0.0.Alpha1 > > > Hibernate Search supports programmatic configuration of indexes, we should add some tests in Infinispan Query to verify the looks of such an API and if it works. > Then document it. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2673) maxEntries = 0 support for eviction

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2673?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2673: ------------------------------------- ISPN-3051 should help with this as well. > maxEntries = 0 support for eviction > ----------------------------------- > > Key: ISPN-2673 > URL: https://issues.jboss.org/browse/ISPN-2673 > Project: Infinispan > Issue Type: Feature Request > Components: Eviction > Affects Versions: 5.2.0.Beta6 > Reporter: Thomas Fromm > Assignee: Mircea Markus > Priority: Minor > > To save memory I'd like to configure maxEntries to 0. > In case I use a Cache to share (possible) big data as entry between nodes. These data are persisted inside store and only used rarely. So I see two ways to realize that: > 1) I can set maxEntries to 0 so that after use the entry is evicted from cache. > 2) Have a cache mode which does not keep data in memory and just work transparent on the store. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-201) make JDBC cache store use DB transactions for commit/rollback

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-201: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > make JDBC cache store use DB transactions for commit/rollback > ------------------------------------------------------------- > > Key: ISPN-201 > URL: https://issues.jboss.org/browse/ISPN-201 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Labels: modshape > > current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach). -- 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

12 years, 9 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 July 2013