[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3693:
--------------------------------
Description:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves value from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
was:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves valule from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry
> t1 -> activates entry
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect sized based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3693:
--------------------------------
Description:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves value from context (dc)
t2 -> passivates entry (writes entry to loader)
t1 -> activates entry (removes entry from loader)
t2 -> removes entry from dc
{code}
Note this doesn't affect size based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
was:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves value from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves value from context (dc)
> t2 -> passivates entry (writes entry to loader)
> t1 -> activates entry (removes entry from loader)
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect size based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3693?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3693:
--------------------------------
Description:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> calls evict retrieves valule from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
was:
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> cals evict retrieves valule from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
> ActivationInterceptor on get always deletes store contents
> ----------------------------------------------------------
>
> Key: ISPN-3693
> URL: https://issues.jboss.org/browse/ISPN-3693
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 6.0.0.CR2
>
>
> The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
> Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
> The following describes this scenario
> {code}
> t1 -> calls get retrieves value from context (dc)
> t2 -> calls evict retrieves valule from context (dc)
> t2 -> passivates entry
> t1 -> activates entry
> t2 -> removes entry from dc
> {code}
> Note this doesn't affect sized based eviction.
> Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3693) ActivationInterceptor on get always deletes store contents
by William Burns (JIRA)
William Burns created ISPN-3693:
-----------------------------------
Summary: ActivationInterceptor on get always deletes store contents
Key: ISPN-3693
URL: https://issues.jboss.org/browse/ISPN-3693
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 6.0.0.CR1
Reporter: William Burns
Assignee: Mircea Markus
Fix For: 6.0.0.CR2
The activation interceptor when doing manual eviction always removes the entry from the loader on a get. This is done even if the entry is in the data container.
Now this is fine for a single invocation. However if a concurrent evict command comes on a different thread you can get in a state where the data is neither in the dc or loader defeating the purpose of Passivation.
The following describes this scenario
{code}
t1 -> calls get retrieves value from context (dc)
t2 -> cals evict retrieves valule from context (dc)
t2 -> passivates entry
t1 -> activates entry
t2 -> removes entry from dc
{code}
Note this doesn't affect sized based eviction.
Also looking closer we need to fix the act of activation. It can cause a window where no data is available between when the loader entry is removed and the data is committed to the data container. This would especially be apparent with tx caches as the data container wouldn't be updated until the tx is completed where as the loader is removed on the get.
--
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, 5 months
[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3558:
---------------------------------------
[~galder.zamarreno] yea discussed but according to [~mircea.markus] it's not as simple as I expected. Asked him to get in touch with you about the general state, specifically if this one issue needs to stay as a blocker or can be downgraded.
> PutForExternalRead won't work after a clear(), when both in same tx
> -------------------------------------------------------------------
>
> Key: ISPN-3558
> URL: https://issues.jboss.org/browse/ISPN-3558
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: William Burns
> Priority: Blocker
> Labels: dm
> Fix For: 6.0.0.Final
>
>
> {code}
> public void testPutForExternalReadAfterClear() throws Exception {
> cache.put(1, "v1");
> tm().begin();
> try {
> cache.getAdvancedCache().clear();
> cache.putForExternalRead(1, "v1");
> assertEquals("v1", cache.get(1));
> } finally {
> tm().commit();
> }
> }
> {code}
--
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, 5 months
[JBoss JIRA] (ISPN-3558) PutForExternalRead won't work after a clear(), when both in same tx
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3558?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3558:
-------------------------------------
[~galderz] it's not as easy as that: if there's no transaction associated with the current thread, then the TxInterceptor will throw an exception. Also we'd need to use a nontxinvocation context, which is a bit more complicated, as the InvocationContextContainer is configured per cache ( and we'd need to change that). I'm not saying that the solution doesn't make sense but that it is not that trivial to implement in the scope of 6.0.
What about this solve the problem with L2 integration? use a distributed executor broadcasted that would invoke DtaContainer.clear and PersistenceManager.clear on all nodes?
> PutForExternalRead won't work after a clear(), when both in same tx
> -------------------------------------------------------------------
>
> Key: ISPN-3558
> URL: https://issues.jboss.org/browse/ISPN-3558
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: William Burns
> Priority: Blocker
> Labels: dm
> Fix For: 6.0.0.Final
>
>
> {code}
> public void testPutForExternalReadAfterClear() throws Exception {
> cache.put(1, "v1");
> tm().begin();
> try {
> cache.getAdvancedCache().clear();
> cache.putForExternalRead(1, "v1");
> assertEquals("v1", cache.get(1));
> } finally {
> tm().commit();
> }
> }
> {code}
--
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, 5 months