[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3451:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1002602
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3451:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1002602|https://bugzilla.redhat.com/show_bug.cgi?id=1002602]
In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
A=1, B=1
startTx
write A=2
write B=2
endTx
if on different node I read B=2, it implies that A=2.
However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-3451:
------------------------------
Description:
In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
A=1, B=1
startTx
write A=2
write B=2
endTx
if on different node I read B=2, it implies that A=2.
However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
was:
In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
A=1, B=1
startTx
write A=2
write B=2
endTx
if on different node I read B=2, it implies that A=2.
However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
That is pretty unexpected semantics. I suggest that the context should use some different structure (linked hash map?) which will be iterated according to the modification order.
Although, this still wouldn't assure the atomicity of transaction for some scenarios.
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3451:
---------------------------------
Summary: Read-after-write semantics in transactional mode
Key: ISPN-3451
URL: https://issues.jboss.org/browse/ISPN-3451
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 6.0.0.Alpha3
Reporter: Radim Vansa
Assignee: Mircea Markus
In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
A=1, B=1
startTx
write A=2
write B=2
endTx
if on different node I read B=2, it implies that A=2.
However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
That is pretty unexpected semantics. I suggest that the context should use some different structure (linked hash map?) which will be iterated according to the modification order.
Although, this still wouldn't assure the atomicity of transaction for some scenarios.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-3449:
------------------------------
Issue Type: Bug (was: Feature Request)
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-3449:
------------------------------
Description:
If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
The command on primary owner succeeds as it does not check whether the responses are successful.
was:
If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the entry won't be in the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
The command on primary owner succeeds as it does not check whether the responses are successful.
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3450) Jon plugin - failing RebuildIndex operation on [MassIndexer] component
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3450?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3450:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> made a comment on [bug 1002550|https://bugzilla.redhat.com/show_bug.cgi?id=1002550]
More info in linked JIRA as usual.
> Jon plugin - failing RebuildIndex operation on [MassIndexer] component
> ----------------------------------------------------------------------
>
> Key: ISPN-3450
> URL: https://issues.jboss.org/browse/ISPN-3450
> Project: Infinispan
> Issue Type: Bug
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
>
> RebuildIndex operation on [MassIndexer] component is failing while issuing in JON with this error:
> java.lang.NullPointerException
> at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> I reused configuration from ISPN test suite + I was able to issue this operation successfully via jconsole tool. That's why I suspect that problems are somewhere in JON-ISPN interaction or plugin.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3450) Jon plugin - failing RebuildIndex operation on [MassIndexer] component
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3450?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3450:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1002550
> Jon plugin - failing RebuildIndex operation on [MassIndexer] component
> ----------------------------------------------------------------------
>
> Key: ISPN-3450
> URL: https://issues.jboss.org/browse/ISPN-3450
> Project: Infinispan
> Issue Type: Bug
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
>
> RebuildIndex operation on [MassIndexer] component is failing while issuing in JON with this error:
> java.lang.NullPointerException
> at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> I reused configuration from ISPN test suite + I was able to issue this operation successfully via jconsole tool. That's why I suspect that problems are somewhere in JON-ISPN interaction or plugin.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3450) Jon plugin - failing RebuildIndex operation on [MassIndexer] component
by Tomas Sykora (JIRA)
Tomas Sykora created ISPN-3450:
----------------------------------
Summary: Jon plugin - failing RebuildIndex operation on [MassIndexer] component
Key: ISPN-3450
URL: https://issues.jboss.org/browse/ISPN-3450
Project: Infinispan
Issue Type: Bug
Reporter: Tomas Sykora
Assignee: Mircea Markus
RebuildIndex operation on [MassIndexer] component is failing while issuing in JON with this error:
java.lang.NullPointerException
at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
I reused configuration from ISPN test suite + I was able to issue this operation successfully via jconsole tool. That's why I suspect that problems are somewhere in JON-ISPN interaction or plugin.
--
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
10 years, 8 months
[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3449:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1002532|https://bugzilla.redhat.com/show_bug.cgi?id=1002532]
If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the entry won't be in the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
The command on primary owner succeeds as it does not check whether the responses are successful.
> ReplaceCommand with ignorePrevValue=true does not work on null entries
> ----------------------------------------------------------------------
>
> Key: ISPN-3449
> URL: https://issues.jboss.org/browse/ISPN-3449
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the entry won't be in the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails.
> The command on primary owner succeeds as it does not check whether the responses are successful.
--
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
10 years, 8 months