- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
private Map<String, PreparedStatement> statements = new ConcurrentHashMap<>();
public PreparedStatement prepare(String cql) {
cql = cql.toLowerCase();
synchronized (cql.intern()) {
if (!statements.containsKey(cql)) {
PreparedStatement statement = session.prepare(cql);
statements.put(cql, statement);
}
}
return statements.get(cql);
}
Follow us!
Нет.
с ConcurrentSkipListMap перепутал
PS
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent-K-java.util.function.Function-
но как здесь описывается, то вроде бы чтение из мапа не будет заблокировано - только запись в мап. не совсем желательно - но часто это достаточно.
Исходники у этого метода, канеш, вырви глаз, но мапа полностью не лочится. Здесь как и везде в конкаррент мапе есть а ля бакеты, которые вычисляются для каждой строки cql. То есть в случае коллизий будет лочиться только один бакет.
Шо это за слово такое? :)
А кто сказал, что session.prepare(cql); потокобезопасен?
Тут смех скорее не в блокировках, а в том, как происходит инвалидация кэша.
Что происходит с PreparedStatement, когда сессия закрывается?
Кто удаляет старые записи из кэша?
"Java uses garbage collection, thus there are no memory leak by design. You simply need to install more RAM on your servers."
Что-то я и сам затупил. Лок тут используется не для того, чтобы защитить session, и не для того, чтобы защитить мапу.
Он тут используется для того, чтобы не подготавливать один и тот же запрос дважды.
Осталось проверить, является ли session потокобезопасным.
Сессия закрывается при остановке приложения. То есть все время жизни приложения PreparedStatement абсолютно валиден.
Наконец-то за сайт взялись
а меня пронесло?