incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Question regarding java DowngradingConsistencyRetryPolicy
Date Wed, 05 Mar 2014 13:16:19 GMT
"INSERT INTO x (a,b.c) values (1,2,3)"

Doesn't this sometimes turn into a batch mutation if b and c are separate
columns?




On Wed, Mar 5, 2014 at 5:03 AM, Sylvain Lebresne <sylvain@datastax.com>wrote:

> Let me first note that the DataStax Java driver has a dedicated mailing
> list:
> https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user,
> it would better to use that list for driver specific questions in the
> future.
>
> But to answer your question, a SIMPLE write is any write (INSERT, UPDATE,
> DELETE) that is not in a batch. Concretely, if you do:
>   session.execute("INSERT INTO ...");
> it's a SIMPLE write.
>
> --
> Sylvain
>
>
> On Tue, Mar 4, 2014 at 7:21 PM, HAITHEM JARRAYA <a-hjarraya@expedia.com>wrote:
>
>> Hi All,
>>
>> I might be missing something and I would like some clarification on this.
>> We are using the java driver with the Downgrading Retry policy, we see in
>> our logs that are only the reads are retried.
>>
>> In the code and the docs, it says that the write method will retry a
>> maximum of one retry, when the WriteType is UNLOGGED_BATCH or BATCH_LOG.
>> My question is, when a write is considered as SIMPLE?
>>
>> Thanks,
>>
>> Haithem
>>
>>     /**
>>      * Defines whether to retry and at which consistency level on a write
>> timeout.
>>      * <p>
>>      * This method triggers a maximum of one retry. If {@code writeType ==
>>      * WriteType.BATCH_LOG}, the write is retried with the initial
>>      * consistency level. If {@code writeType == WriteType.UNLOGGED_BATCH}
>>      * and at least one replica acknowledged, the write is retried with a
>>      * lower consistency level (with unlogged batch, a write timeout can
>>      * <b>always</b> mean that part of the batch haven't been persisted
at
>>      * all, even if {@code receivedAcks > 0}). For other {@code
>> writeType},
>>      * if we know the write has been persisted on at least one replica, we
>>      * ignore the exception. Otherwise, an exception is thrown.
>>      *
>>      * @param statement the original query that timed out.
>>      * @param cl the original consistency level of the write that timed
>> out.
>>      * @param writeType the type of the write that timed out.
>>      * @param requiredAcks the number of acknowledgments that were
>> required to
>>      * achieve the requested consistency level.
>>      * @param receivedAcks the number of acknowledgments that had been
>> received
>>      * by the time the timeout exception was raised.
>>      * @param nbRetry the number of retry already performed for this
>> operation.
>>      * @return a RetryDecision as defined above.
>>      */
>>     @Override
>>     public RetryDecision onWriteTimeout(Statement statement,
>> ConsistencyLevel cl, WriteType writeType, int requiredAcks, int
>> receivedAcks, int nbRetry) {
>>         if (nbRetry != 0)
>>             return RetryDecision.rethrow();
>>
>>         switch (writeType) {
>>             case SIMPLE:
>>             case BATCH:
>>                 // Since we provide atomicity there is no point in
>> retrying
>>                 return RetryDecision.ignore();
>>             case UNLOGGED_BATCH:
>>                 // Since only part of the batch could have been persisted,
>>                 // retry with whatever consistency should allow to
>> persist all
>>                 return maxLikelyToWorkCL(receivedAcks);
>>             case BATCH_LOG:
>>                 return RetryDecision.retry(cl);
>>         }
>>         // We want to rethrow on COUNTER and CAS, because in those case
>> "we don't know" and don't want to guess
>>         return RetryDecision.rethrow();
>>     }
>>
>>
>>
>

Mime
View raw message