[JBoss JIRA] (ISPN-5141) SingleFileStore.process() should use sequential access
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5141?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-5141:
----------------------------------
Assignee: Dan Berindei
> SingleFileStore.process() should use sequential access
> ------------------------------------------------------
>
> Key: ISPN-5141
> URL: https://issues.jboss.org/browse/ISPN-5141
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.3.Final, 7.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> {{SingleFileStore.process()}} iterates over its keys in pseudo-random order. (It puts all the entries in a {{HashSet}} and iterates it to minimize the amount of time it keeps the global lock.)
> It should instead either iterate the entries directly from the disk, or at least sort the entries by their offset when iterating.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Richard Lucas (JIRA)
[ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.s... ]
Richard Lucas edited comment on ISPN-201 at 2/6/15 1:09 PM:
------------------------------------------------------------
After discussions with [~NadirX] and [~hchiorean] I would like to propose that this issue is revisited given the impact it has on using Modeshape as a consistent/durable database (see MODE-2420 for more information about this).
This use case only makes sense in certain scenarios e.g. a shared/single transactional cache store where the originator node performs all the writes (which is a common use case when using ModeShape).
My preference would be to implement option 2) as the first option (given the current writes are done in the commit phase) will result in the the cache store/cache being correctly rolled back but will leave the cache transaction 'in-doubt/failed'. I have an experimental build of Infinispan 6.0.2.Final that implements a simple version of option 1) (see https://github.com/lucasweb78/infinispan/tree/6.0.2.Final.PepeDigital) and although it does ensure cache store consistency having to deal with the 'in-doubt/failed transaction' in the application tier is not ideal (see this discussion https://developer.jboss.org/thread/251902 for further details about this)
Option 2) is not without it's challenges (I did investigate implementing it but ran into issues). I was able to get the cache store to participate as an XA Resource in the cache transaction but run into problems with the way the modifications are currently written to the cache store by the CacheWriterInterceptor.
Currently (when using Tx) all writes are done in the commit phase after all modifications have been registered with the Tx. In order to have the Cache Store enlist as an XA resource the writes need to be done prior to the prepare phase. Currently this means doing the write as part of the modification command e.g. put (which is how non Tx caches work). I modified the CacheWriter to do this and it worked but I ran into problems with the following scenario:
{noformat}
cache.put(key, object);
object.setValue(someValue);
{noformat}
Given the above the cache store would contain object prior to the setValue (as it was written to prior to to the change) call but the cache would contain the object with the updated value (as it was written to in the commit phase after the change). Unfortunately the above scenario is used in many places in Modeshape which is why I reverted to option 1.
One option to resolve this is to delay the writes to the store to just before the prepare phase but after all modifications have been registered with the Tx. Not only would it solve this issue but would also allow for new functionality which could pass modifications in batch to a store in single call (see ISPN-5210). There a several advantages to this including the ability to perform batch inserts/updates on the underlying store which is generally more efficient and allow non-tx stores a chance to clean up if an error occurs while writing in batch (e.g. MongoDB, DynamoDB store implementations could use this to provide a more robust integration with Infinispan).
was (Author: ma6rl):
After discussions with [~NadirX] and [~hchiorean] I would like to propose that this issue is revisited given the impact it has on using Modeshape as a consistent/durable database (see MODE-2420 for more information about this).
This use case only makes sense in certain scenarios e.g. a shared/single transactional cache store where the originator node performs all the writes (which is a common use case when using ModeShape).
My preference would be to implement option 2) as the first option (given the current writes are done in the commit phase) will result in the the cache store/cache being correctly rolled back but will leave the cache transaction 'in-doubt/failed'. I have an experimental build of Infinispan 6.0.2.Final that implements a simple version of option 1) (see https://github.com/lucasweb78/infinispan/tree/6.0.2.Final.PepeDigital) and although it does ensure cache store consistency having to deal with the 'in-doubt/failed transaction' in the application tier is not ideal (see this discussion https://developer.jboss.org/thread/251902 for further details about this)
Option 2) is not without it's challenges (I did investigate implementing it but ran into issues). I was able to get the cache store to participate as an XA Resource in the cache transaction but run into problems with the way the modifications are currently written to the cache store by the CacheWriterInterceptor.
Currently (when using Tx) all writes are done in the commit phase after all modifications have been registered with the Tx. In order to have the Cache Store enlist as an XA resource the writes need to be done prior to the prepare phase. Currently this means doing the write as part of the modification command e.g. put (which is how non Tx caches work). I modified the CacheWriter to do this and it worked but I ran into problems with the following scenario:
{noformat}
cache.put(key, object);
object.setValue(someValue);
{noformat}
Given the above the cache store would contain object prior to the setValue (as it was written to prior to to the change) call but the cache would contain the object with the updated value (as it was written to in the commit phase after the change). Unfortunately the above scenario is used in many places in Modeshape which is why I reverted to option 1.
One option to resolve this is to delay the writes to the store to just before the prepare phase but after all modifications have been registered with the Tx. Not only would it solve this issue but would also allow for new functionality which could pass modifications in batch to a store in single call. There a several advantages to this including the ability to perform batch inserts/updates on the underlying store which is generally more efficient and allow non-tx stores a chance to clean up if an error occurs while writing in batch (e.g. MongoDB, DynamoDB store implementations could use this to provide a more robust integration with Infinispan).
> 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
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5210) Support writing multiple modifications to cache stores in batch when using Transactions
by Richard Lucas (JIRA)
Richard Lucas created ISPN-5210:
-----------------------------------
Summary: Support writing multiple modifications to cache stores in batch when using Transactions
Key: ISPN-5210
URL: https://issues.jboss.org/browse/ISPN-5210
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Affects Versions: 7.1.0.Final, 6.0.2.Final
Reporter: Richard Lucas
Currently writes to a cache store are performed individually for each modification to the cache.
While this makes sense when using a non-tx cache it would be beneficial to support writing multiple modifications to a cache store in a single call when using a Tx cache.
Currently all writes are performed in the commit phase and are done by looping through the modifications in the Tx and writing each one in turn to the the store.
Instead of doing this it would useful to pass all modifications to the store in a single call, this would allow:
a) Taking advantage of support for batch updates in underlying stores (JDBC, MongoDB, DynamoDB) for a more efficient write through.
b) Allow store implementations the chance to clean up if one or more updates in the batch fail (this is especially useful if the store does not support Tx and rollbacks as it means the store implementation can at least try to clean up any partial updates it has performed, something which is not currently possible).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Richard Lucas (JIRA)
[ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.s... ]
Richard Lucas commented on ISPN-201:
------------------------------------
After discussions with [~NadirX] and [~hchiorean] I would like to propose that this issue is revisited given the impact it has on using Modeshape as a consistent/durable database (see MODE-2420 for more information about this).
This use case only makes sense in certain scenarios e.g. a shared/single transactional cache store where the originator node performs all the writes (which is a common use case when using ModeShape).
My preference would be to implement option 2) as the first option (given the current writes are done in the commit phase) will result in the the cache store/cache being correctly rolled back but will leave the cache transaction 'in-doubt/failed'. I have an experimental build of Infinispan 6.0.2.Final that implements a simple version of option 1) (see https://github.com/lucasweb78/infinispan/tree/6.0.2.Final.PepeDigital) and although it does ensure cache store consistency having to deal with the 'in-doubt/failed transaction' in the application tier is not ideal (see this discussion https://developer.jboss.org/thread/251902 for further details about this)
Option 2) is not without it's challenges (I did investigate implementing it but ran into issues). I was able to get the cache store to participate as an XA Resource in the cache transaction but run into problems with the way the modifications are currently written to the cache store by the CacheWriterInterceptor.
Currently (when using Tx) all writes are done in the commit phase after all modifications have been registered with the Tx. In order to have the Cache Store enlist as an XA resource the writes need to be done prior to the prepare phase. Currently this means doing the write as part of the modification command e.g. put (which is how non Tx caches work). I modified the CacheWriter to do this and it worked but I ran into problems with the following scenario:
{noformat}
cache.put(key, object);
object.setValue(someValue);
{noformat}
Given the above the cache store would contain object prior to the setValue (as it was written to prior to to the change) call but the cache would contain the object with the updated value (as it was written to in the commit phase after the change). Unfortunately the above scenario is used in many places in Modeshape which is why I reverted to option 1.
One option to resolve this is to delay the writes to the store to just before the prepare phase but after all modifications have been registered with the Tx. Not only would it solve this issue but would also allow for new functionality which could pass modifications in batch to a store in single call. There a several advantages to this including the ability to perform batch inserts/updates on the underlying store which is generally more efficient and allow non-tx stores a chance to clean up if an error occurs while writing in batch (e.g. MongoDB, DynamoDB store implementations could use this to provide a more robust integration with Infinispan).
> 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
> 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 was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5174) Transaction cannot be recommitted after ownership changes
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5174?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5174 started by Dan Berindei.
------------------------------------------
> Transaction cannot be recommitted after ownership changes
> ---------------------------------------------------------
>
> Key: ISPN-5174
> URL: https://issues.jboss.org/browse/ISPN-5174
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.1.0.CR2
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> Once transaction is completed, it cannot commit again. If it should commit more keys since it has become an owner of some new keys modified in this transaction, it just ignores the further commit.
> There is a race with state transfer which can bring an old value (with StateResponseCommand sent before it is commited) but the value is not set by the ongoing transaction either.
> This results with stale value stored on one node.
> In my case, The problematic part is transaction <edg-perf01-62141>:15066 (consisting of 10 modifications) which got prepared and committed on edg-perf04 in topology 25. Before the originator finishes, topology changes and 04 requests ongoing transactions:
> {code}
> 11:06:11,369 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (transport-thread-17) Replication task sending StateRequestCommand{cache=testCache, origin=edg-perf04-35097, type=GET_TRANSACTIONS, topologyId=28, segments=[275, 1, 278, 9, 282, 286, 17, 259, 25, 267, 171, 169, 33, 306, 175, 173, 310, 172, 314, 41, 167, 165, 318, 187, 290, 49, 185, 191, 294, 189, 179, 298, 57, 177, 183, 302, 181, 343, 205, 201, 338, 203, 336, 351, 197, 349, 199, 347, 193, 345, 195, 326, 85, 87, 322, 93, 332, 95, 330, 89, 91, 103, 101, 99, 506, 97, 105, 357, 359, 353, 355, 361]} to single recipient edg-perf01-62141 with response mode GET_ALL
> 11:06:11,495 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread-17) Applying 6 transactions for cache testCache transferred from node edg-perf01-62141
> {code}
> However I don't see how these are applied, since PrepareCommand is not created again - from the code I see only that backup locks are added. Not sure if the transaction is registered at all, since it was already completed on this node (but at that time it did not own key_00000000000002EB).
> After originator stores the entry, it sends one more CommitCommand with topology 28:
> {code}
> 11:06:11,619 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-2) Replication task sending CommitCommand {gtx=GlobalTransaction:<edg-perf01-62141>:15066:local, cacheName='testCache', topologyId=28} to addresses [edg-perf03-20530, edg-perf04-35097] with response mode GET_ALL
> {code}
> 04 receives several CommitCommands (both from originator and forwards), but all of them are ignored as the transaction is completed.
> I don't see the logs where state transfer is assembled, but it's probably before the entry is stored on originator as the state transfer contains the old entry:
> {code}
> 11:06:13,449 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-91) Received chunk with keys [key_000000000000065B, key_00000000000006BE, key_FFFFFFFFFFFFE62F, key_0000000000001F42, key_000000000000027B, key_000000000000159D, key_00000000000002EB, key_00000000000002BB] for segment 343 of cache testCache from node edg-perf01-62141
> 11:06:13,454 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-91) Store ImmortalCacheEntry{key=key_00000000000002EB, value=[2 #7: 366, 544, 576, 804, 1061, 1181, 1290, ]} in container
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months