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

[Richard Lucas (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038508#comment-13038508 ] 

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)