setting consistency level from property

user_5945472 0
Viewed 63

I'm using dse driver 3.6.8, java 8, spring 3.2.18 I'm trying to set different consistency levels for each table The desired consitency levels are stored in a propoerty file

<entry key="consistency.level.strongWriteLevel">EACH_QUORUM</entry>
<entry key="consistency.level.strongReadLevel">LOCAL_QUORUM</entry>
<entry key="consistency.level.lightWriteLevel">TWO</entry>
<entry key="consistency.level.lightReadLevel">ONE</entry>

I tried this

@Component
@Table(name = "someName",
        readConsistency = "${consistency.level.strongReadLevel}",
        writeConsistency = "${consistency.level.strongWriteLevel}")
public class MMBaseLoginHistory {

but it didn't work. I know I can set the CL on the mapper which overrides the @Table CL, but I wanted to know at least if it was possible.

I tried multiple variations of this code, with or without @Component by adding a field

@Value("${consistency.level.strongReadLevel}")
private String strongReadLevel;

and then try to reffer to it

@Component
@Table(name = "someName",
        readConsistency = strongReadLevel)
public class MMBaseLoginHistory {

none of the previous worked

EDIT: I found this solution, but it doesn't stisfies me at all

import static com.cardlinkin.mm.model.beans.MMBaseLoginHistory.writeConsistencyLevel;
import static com.cardlinkin.mm.model.beans.MMBaseLoginHistory.readConsistencyLevel;

@Component
@Table(name = "someName",
        writeConsistency = writeConsistencyLevel,
        readConsistency = readConsistencyLevel)
public class MMBaseLoginHistory {

    @Value("${consistency.level.strongWriteLevel}")
    public static final String writeConsistencyLevel = "";
    @Value("${consistency.level.strongReadLevel}")
    public static final  String readConsistencyLevel = "";
datastax-java-driver cassandra
1 Answers

This isn't a direct answer to your question but I wanted to point out that our general recommendation is to use LOCAL_QUORUM for both reads and writes. There are very limited edge cases where other consistency levels such as ONE is an appropriate choice.

For example, EACH_QUORUM is very expensive and you need to be fully aware of the penalty you'll incur in situations where the Cassandra DCs are in different geographic locations. The price of requiring quorum acknowledgements from remote DCs can be very costly the higher the latency is across the network.

If the C* DCs are located in the same physical location, or if the distance/latency between the DCs is very negligible then the cost of EACH_QUORUM is low and you should expect that the mutations are replicated successfully so there's no real benefit using an expensive CL.

Similarly, a consistency of ONE is only recommended for use cases where consistency really doesn't matter. For example a social feed where if a post doesn't appear on someone's timeline, it won't make a huge difference since the user will see the post the next time they refresh their feed. Cheers!

user_42695350
Related