[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3664:
------------------------------
Description:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
Note that most of the interceptor only needs to implement the visitWriteCommand because all the write command has the same execution flow. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change. for tx mode, lock (if pessimistic), fetch value (cache loader, remote, etc), apply change and add it to the transaction (if successful)
Also, another advantage is the simplification of the EntryFactory because if we think a little about it, independent of the write command we need to wrap the entry anyway.
Suggested implementation
{code:java}
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
{code}
* Concrete implementations*
{code:java}
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
{code}
* Special base class for operation with expected value to compare*
{code:java}
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
{code}
ps: I'm going to open the discussion in the dev mailing list...
was:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
{code:java}
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
{code}
* Concrete implementations*
{code:java}
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
{code}
* Special base class for operation with expected value to compare*
{code:java}
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
{code}
ps: I'm going to open the discussion in the dev mailing list...
> Improve write command processing
> --------------------------------
>
> Key: ISPN-3664
> URL: https://issues.jboss.org/browse/ISPN-3664
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Final
>
>
> Major refactorization of the write command with the following goals:
> -> Base WriteCommand: all the write command has the same workflow through the interceptor chain
> -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
> -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
> -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
> Note that most of the interceptor only needs to implement the visitWriteCommand because all the write command has the same execution flow. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change. for tx mode, lock (if pessimistic), fetch value (cache loader, remote, etc), apply change and add it to the transaction (if successful)
> Also, another advantage is the simplification of the EntryFactory because if we think a little about it, independent of the write command we need to wrap the entry anyway.
> Suggested implementation
> {code:java}
> class abstract WriteCommand
> Object key, Object newValue
> boolen match(Object currentValue) //true by default
> boolean needsRemoteGetBeforeWrite() //true by default
> object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
> {code}
> * Concrete implementations*
> {code:java}
> {PutCommand|RemoveCommand} extends WriteCommand
> ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
> ReplaceIfPresentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue != null}
> PutIfAbsentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue == null}
> {code}
> * Special base class for operation with expected value to compare*
> {code:java}
> class abstract AdvancedWriteCommand extends WriteCommand
> Object expectedValue
> match(Object currentValue) {return currentValue.equals(expectedValue)}
> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
> {code}
> ps: I'm going to open the discussion in the dev mailing list...
--
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, 2 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-3665:
-------------------------------
Attachment: Test.java
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 6.0.0.Final
>
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable operation (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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, 2 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-3665:
-------------------------------
Description:
SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
I've attached a test to reproduce the problem.
I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit.
I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
was:
SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
I've attached a test to reproduce the problem.
I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
A proper fix should probably make this a configurable operation (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit.
I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 6.0.0.Final
>
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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, 2 months
[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3664:
------------------------------
Description:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
{code:java}
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
{code}
* Concrete implementations*
{code:java}
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
{code}
* Special base class for operation with expected value to compare*
{code:java}
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
{code}
ps: I'm going to open the discussion in the dev mailing list...
was:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
{code:java}
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
{code}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
> Improve write command processing
> --------------------------------
>
> Key: ISPN-3664
> URL: https://issues.jboss.org/browse/ISPN-3664
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Final
>
>
> Major refactorization of the write command with the following goals:
> -> Base WriteCommand: all the write command has the same workflow through the interceptor chain
> -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
> -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
> -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
> The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
> Suggested implementation
> {code:java}
> class abstract WriteCommand
> Object key, Object newValue
> boolen match(Object currentValue) //true by default
> boolean needsRemoteGetBeforeWrite() //true by default
> object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
> {code}
> * Concrete implementations*
> {code:java}
> {PutCommand|RemoveCommand} extends WriteCommand
> ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
> ReplaceIfPresentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue != null}
> PutIfAbsentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue == null}
> {code}
> * Special base class for operation with expected value to compare*
> {code:java}
> class abstract AdvancedWriteCommand extends WriteCommand
> Object expectedValue
> match(Object currentValue) {return currentValue.equals(expectedValue)}
> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
> {code}
> ps: I'm going to open the discussion in the dev mailing list...
--
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, 2 months
[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3664:
------------------------------
Description:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
{code:java}
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
{code}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
was:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
> Improve write command processing
> --------------------------------
>
> Key: ISPN-3664
> URL: https://issues.jboss.org/browse/ISPN-3664
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Final
>
>
> Major refactorization of the write command with the following goals:
> -> Base WriteCommand: all the write command has the same workflow through the interceptor chain
> -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
> -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
> -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
> The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
> Suggested implementation
> {code:java}
> class abstract WriteCommand
> Object key, Object newValue
> boolen match(Object currentValue) //true by default
> boolean needsRemoteGetBeforeWrite() //true by default
> object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
> {code}
> * Concrete implementations*
> {PutCommand|RemoveCommand} extends WriteCommand
> ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
> ReplaceIfPresentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue != null}
> PutIfAbsentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue == null}
> * Special base class for operation with expected value to compare*
> class abstract AdvancedWriteCommand extends WriteCommand
> Object expectedValue
> match(Object currentValue) {return currentValue.equals(expectedValue)}
> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
> ps: I'm going to open the discussion in the dev mailing list...
--
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, 2 months
[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3664:
---------------------------------
Summary: Improve write command processing
Key: ISPN-3664
URL: https://issues.jboss.org/browse/ISPN-3664
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 6.0.0.CR1
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 7.0.0.Final
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
--
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, 2 months
[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3664:
------------------------------
Description:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
was:
Major refactorization of the write command with the following goals:
-> Base WriteCommand: all the write command has the same workflow through the interceptor chain
-> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
-> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
-> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
Suggested implementation
class abstract WriteCommand
Object key, Object newValue
boolen match(Object currentValue) //true by default
boolean needsRemoteGetBeforeWrite() //true by default
object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
* Concrete implementations*
{PutCommand|RemoveCommand} extends WriteCommand
ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
ReplaceIfPresentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue != null}
PutIfAbsentCommand extends WriteCommand
ovewrite match(Object currentValue) {return currentValue == null}
* Special base class for operation with expected value to compare*
class abstract AdvancedWriteCommand extends WriteCommand
Object expectedValue
match(Object currentValue) {return currentValue.equals(expectedValue)}
{RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
ps: I'm going to open the discussion in the dev mailing list...
> Improve write command processing
> --------------------------------
>
> Key: ISPN-3664
> URL: https://issues.jboss.org/browse/ISPN-3664
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.0.0.Final
>
>
> Major refactorization of the write command with the following goals:
> -> Base WriteCommand: all the write command has the same workflow through the interceptor chain
> -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
> -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
> -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
> The above it is safe and it would make the code simple. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change
> Suggested implementation
> class abstract WriteCommand
> Object key, Object newValue
> boolen match(Object currentValue) //true by default
> boolean needsRemoteGetBeforeWrite() //true by default
> object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
> * Concrete implementations*
> {PutCommand|RemoveCommand} extends WriteCommand
> ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
> ReplaceIfPresentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue != null}
> PutIfAbsentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue == null}
> * Special base class for operation with expected value to compare*
> class abstract AdvancedWriteCommand extends WriteCommand
> Object expectedValue
> match(Object currentValue) {return currentValue.equals(expectedValue)}
> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
> ps: I'm going to open the discussion in the dev mailing list...
--
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, 2 months
[JBoss JIRA] (ISPN-3614) Add remote query quick start/demo
by Divya Mehra (JIRA)
[ https://issues.jboss.org/browse/ISPN-3614?page=com.atlassian.jira.plugin.... ]
Divya Mehra commented on ISPN-3614:
-----------------------------------
Referring to Mircea's comment above, this custom cache store should work in both Embedded and Client-server modes, without requiring any change to its code, as long the data is in Compatibility mode ISPN-2281.
> Add remote query quick start/demo
> ---------------------------------
>
> Key: ISPN-3614
> URL: https://issues.jboss.org/browse/ISPN-3614
> Project: Infinispan
> Issue Type: Task
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Fix For: 6.0.0.CR2
>
>
> Should describe how the users:
> - download the servers
> - configure it (indexing ...)
> - with sample domain model, how to write the marshallers, define the indexes using the RHQ plugin
> - some code that connects to the server, adds and queries the data (mvn module?)
--
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, 2 months
[JBoss JIRA] (ISPN-3614) Add remote query quick start
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3614?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3614:
-------------------------------------
Also a very nice extension of this (as requested by ISPN-3660) is a cache store (persistence) with the the following characteristics:
1. server configured with an protobuf2javaobject marshaller
2. a custom CacheWriter implementation that uses the java objects as deserialized by the marshaller at 1 in order to persist the entries. It is important for this custom cache writer to be able to use the object format of the objects to store (vs. the protobuf) in order to proof the functionality required by ISPN-3660.
> Add remote query quick start
> ----------------------------
>
> Key: ISPN-3614
> URL: https://issues.jboss.org/browse/ISPN-3614
> Project: Infinispan
> Issue Type: Task
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Fix For: 6.0.0.CR2
>
>
> Should describe how the users:
> - download the servers
> - configure it (indexing ...)
> - with sample domain model, how to write the marshallers, define the indexes using the RHQ plugin
> - some code that connects to the server, adds and queries the data (mvn module?)
--
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, 2 months