[
https://issues.apache.org/jira/browse/MAILBOX-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tellier Benoit updated MAILBOX-209:
-----------------------------------
Attachment: fix_cassandra_modseq_provider.patch
In this patch, we first get the current modseq value. We increase it only if
the value did not change. If it is the case, we can then return the incremented
value. If it is not the case, we just retry.
Note a tunnable max retry parameter ( to avoid being stuck )
To validate all cassandra unit tests ( mailbox mappers espacially ), it has to
behave well even if the mailbox does not exist. Hence the separated table.
> A data race is possible with Cassandra modseq generation
> --------------------------------------------------------
>
> Key: MAILBOX-209
> URL: https://issues.apache.org/jira/browse/MAILBOX-209
> Project: James Mailbox
> Issue Type: Bug
> Reporter: Tellier Benoit
> Attachments: fix_cassandra_modseq_provider.patch
>
>
> The Cassandra mailbox implementation proceed as follow to increase the modseq
> :
> - a first call to Cassandra to increase the modseq value for a given mailbox
> - a second call allow us to retrieve the current value.
> Note that you can not do it in a single call...
> In a distributed environment, imagine that :
> - for a mailbox the current modseq is n
> - server A increments modseq. Modseq is n+1
> - server B increments modseq. Modseq is n+2
> - server A and B then retrieve the modseq value and have a duplicated modseq
> : they for instance both can assign n+2 value to a different message.
> The problem can be solved using conditionnal updates with lightweight
> transactions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
