Forem: Olga Lugacheva

🏰 Легенда о пяти рыцарях SOLID

Olga Lugacheva — Mon, 01 Sep 2025 16:54:08 +0000

Говорят, в Королевстве Кода однажды поселился страшный дракон Спагеттиус. Он пожирал проекты и превращал их в хаос ошибок. Тогда Великий Архитектор созвал пятерых рыцарей, которые поклялись защищать программистов. Каждый рыцарь нёс свой закон.

S — Sir Single Responsibility (Принцип единственной ответственности)

В королевстве жил Класс-Повар, который и готовил еду, и собирал налоги, и управлял армией:

class RoyalManager {
    public void cookFood() {
        System.out.println("Готовлю еду...");
    }

    public void collectTaxes() {
        System.out.println("Собираю налоги...");
    }

    public void leadArmy() {
        System.out.println("Веду армию в бой!");
    }
}

Но когда дракон напал, повар забыл о супе, налогах и войне одновременно. Королевство погрузилось в хаос.

Тогда рыцарь объявил:
— Каждый должен делать своё дело.

class Chef {
    public void cookFood() {
        System.out.println("Готовлю еду...");
    }
}

class TaxCollector {
    public void collectTaxes() {
        System.out.println("Собираю налоги...");
    }
}

class General {
    public void leadArmy() {
        System.out.println("Веду армию в бой!");
    }
}

Теперь каждый выполнял только одну обязанность, и порядок был восстановлен.

⚔️ O — Lady Open-Closed (Принцип открытости/закрытости)

В замке жили заклинатели налогов. Но каждый раз, когда появлялся новый налог, они переписывали старые заклинания. Код ломался.

class TaxCalculator {
    public double calculateTax(String type, double amount) {
        if ("income".equals(type)) {
            return amount * 0.13;
        } else if ("property".equals(type)) {
            return amount * 0.02;
        } else {
            return 0;
        }
    }
}

Lady Open-Closed провозгласила:
— Не разрушай то, что работает. Добавляй новое, не ломая старое.

interface Tax {
    double calculate(double amount);
}

class IncomeTax implements Tax {
    public double calculate(double amount) {
        return amount * 0.13;
    }
}

class PropertyTax implements Tax {
    public double calculate(double amount) {
        return amount * 0.02;
    }
}

class TaxCalculator {
    public double calculateTax(Tax tax, double amount) {
        return tax.calculate(amount);
    }
}

Теперь появлялись новые налоги без переписывания старых.

🧭 L — Sir Liskov Substitution (Принцип подстановки Барбары Лисков)

Однажды решили заменить боевого коня на страуса. Но страус не мог скакать!

class Horse {
    public void ride() {
        System.out.println("Скачу в бой!");
    }
}

class Ostrich extends Horse {
    @Override
    public void ride() {
        throw new UnsupportedOperationException("Я не умею скакать!");
    }
}

Армия осталась без кавалерии.

Рыцарь сказал:
— Если заменяешь наследника на родителя — всё должно работать так же.

interface Rideable {
    void ride();
}

class Horse implements Rideable {
    public void ride() {
        System.out.println("Скачу в бой!");
    }
}

class Camel implements Rideable {
    public void ride() {
        System.out.println("Спокойно иду по пустыне.");
    }
}

Теперь любого скакуна можно заменить другим — армия не теряет строй.

⚙️ I — Lady Interface Segregation (Принцип разделения интерфейсов)

В королевстве был свиток “Все-Законы”. Каждый подданный должен был читать его целиком: и про магию, и про налоги, и про войну.

interface KingdomDuties {
    void cookFood();
    void fight();
    void collectTaxes();
}

Даже мирные крестьяне должны были уметь сражаться и собирать налоги.

Lady Interface Segregation заявила:
— Пусть каждый читает только то, что ему нужно.

interface Cook {
    void cookFood();
}

interface Warrior {
    void fight();
}

interface TaxCollector {
    void collectTaxes();
}

class Peasant implements Cook {
    public void cookFood() {
        System.out.println("Варю похлёбку.");
    }
}

class Soldier implements Warrior {
    public void fight() {
        System.out.println("Сражаюсь с врагами!");
    }
}

Теперь каждый выполнял лишь свою обязанность.

🧙 D — Lord Dependency Inversion (Принцип инверсии зависимостей)

Программисты писали коды-заклинания, которые зависели от конкретных мечей. Но если меч ломался — всё рушилось.

class Sword {
    public void attack() {
        System.out.println("Удар мечом!");
    }
}

class Warrior {
    private Sword sword = new Sword();

    public void fight() {
        sword.attack();
    }
}

Lord Dependency Inversion:
— Пусть герои зависят от идей, а не от деталей.

interface Weapon {
    void attack();
}

class Sword implements Weapon {
    public void attack() {
        System.out.println("Удар мечом!");
    }
}

class Bow implements Weapon {
    public void attack() {
        System.out.println("Выстрел из лука!");
    }
}

class Warrior {
    private Weapon weapon;

    public Warrior(Weapon weapon) {
        this.weapon = weapon;
    }

    public void fight() {
        weapon.attack();
    }
}

Теперь воин мог взять меч, лук или копьё — и быть готовым к битве.

Когда пять рыцарей объединили силы, Королевство Кода стало непобедимым. Дракон Спагеттиус был повержен, и каждый ученик, кто хотел стать мастером, проходил через их школу.

И до сих пор программисты вспоминают: SOLID — это не сухая теория, а пять рыцарей, которые хранят наш код от хаоса.

☁️ Три кота и облачное королевство Spring. Часть 1 Введение в микросервисную архитектуру

Olga Lugacheva — Fri, 28 Mar 2025 19:17:47 +0000

📖 Глава 1: "Как три кота построили облачный город"

Жили-были три кота: Изи 🐱, Санни 🐱 и Фанни 🐱. Они мечтали построить удобный облачный город для всех кошек, где можно было бы легко регистрироваться, заказывать еду и быстро оплачивать покупки.

Сначала коты решили сделать огромный дворец, где будет один большой сервис для всего. В этом сервисе обрабатывались и пользователи, и заказы, и платежи. Такой подход называется монолитной архитектурой.

Но вскоре возникли проблемы:

Если ломалась одна часть, страдали все. Если падал сервис оплаты, коты не могли даже зарегистрироваться!

Добавлять новые функции стало сложно. Каждый раз, когда Санни хотел добавить новый тип заказа, приходилось изменять огромный код монолита.

Масштабировать было трудно. Когда пользователей стало больше, котам нужно было запускать целый сервис, даже если нагрузка была только на оплату.

"Так не пойдёт!" — сказали коты. "Давайте разделим наш город на независимые дома, каждый из которых будет заниматься своим делом!"

Так они перешли на микросервисную архитектуру, где каждый сервис — это свой домик в облачном городе. Этот город теперь можно легко расширять, добавляя новые дома-сервисы без ущерба для остальных.

🏠 Разбивка на три облачных сервиса

Теперь у каждого кота была своя ответственность:

Сервис пользователей (“User Service”) — отвечает за регистрацию и авторизацию. Управляет Изи 🐱. Ее дом — это городская администрация.

Сервис заказов (“Order Service”) — отвечает за создание и управление заказами. Управляет Санни 🐱. Его дом — это ресторанная площадь.

Сервис оплаты (“Payment Service”) — отвечает за платежи и баланс. Управляет Фанни 🐱. Её дом — это банк в центре города.

Теперь, если банк временно закроется, рестораны и администрация продолжат работать. А если в ресторанах много посетителей, можно просто открыть ещё один ресторан (экземпляр сервиса заказов), не трогая остальные.

🚀 Создание первых облачных сервисов

Допущения

На данном этапе рассматриваются только контроллеры, без сервисного и репозиторного слоёв. В будущем коты улучшат свой город, добавив обработку бизнес-логики и работу с базами данных.

Maven-конфигурация

Перед тем как начать, убедимся, что у нас есть базовый pom.xml для каждого сервиса:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
</dependencies>

🐱 Сервис пользователей (User Service) — городская администрация

@RestController
@RequestMapping("/users")
public class UserController {
    private final Map<Long, String> users = new HashMap<>();

    @PostMapping("/register")
    public ResponseEntity<String> registerUser(@RequestParam String name) {
        long id = users.size() + 1;
        users.put(id, name);
        return ResponseEntity.ok("Пользователь зарегистрирован с ID: " + id);
    }

    @GetMapping("/{id}")
    public ResponseEntity<String> getUser(@PathVariable Long id) {
        return users.containsKey(id) ? 
            ResponseEntity.ok("Имя пользователя: " + users.get(id)) : 
            ResponseEntity.notFound().build();
    }
}

🐱 Сервис заказов (Order Service) — ресторанная площадь

@RestController
@RequestMapping("/orders")
public class OrderController {
    private final List<String> orders = new ArrayList<>();

    @PostMapping("/create")
    public ResponseEntity<String> createOrder(@RequestParam String item) {
        orders.add(item);
        return ResponseEntity.ok("Заказ создан: " + item);
    }

    @GetMapping
    public ResponseEntity<List<String>> getOrders() {
        return ResponseEntity.ok(orders);
    }
}

@RestController
@RequestMapping("/payments")
public class PaymentController {
    private final Map<Long, Double> balances = new HashMap<>();

    @PostMapping("/pay")
    public ResponseEntity<String> makePayment(@RequestParam Long userId, @RequestParam double amount) {
        balances.put(userId, balances.getOrDefault(userId, 0.0) - amount);
        return ResponseEntity.ok("Оплата на сумму " + amount + " выполнена.");
    }

    @GetMapping("/{userId}")
    public ResponseEntity<String> getBalance(@PathVariable Long userId) {
        return balances.containsKey(userId) ? 
            ResponseEntity.ok("Баланс: " + balances.get(userId)) : 
            ResponseEntity.notFound().build();
    }
}

☁️ Как облачные сервисы взаимодействуют?

Теперь сервисы работают отдельно, но иногда нужно, чтобы они общались. Например, перед тем как создать заказ, надо убедиться, что пользователь существует.

Для этого сервис заказов может вызывать сервис пользователей через REST API:

RestTemplate restTemplate = new RestTemplate();
String userExists = restTemplate.getForObject("http://localhost:8081/users/" + userId, String.class);
if (userExists == null) {
    return ResponseEntity.badRequest().body("Пользователь не найден!");
}

Но такой способ плох, потому что сервисы жёстко связаны. Например:

1) Сервис заказов не знает, существует ли пользователь.
Прежде чем создать заказ, нужно проверить, зарегистрирован ли пользователь. Сейчас Order Service делает REST-запрос к User Service, но если тот временно недоступен, заказ не получится создать.

2) Сервис оплаты не может проверить заказ.
Перед оплатой нужно убедиться, что заказ существует и его статус корректен. Сейчас Payment Service должен отправлять запрос в Order Service, что создаёт жёсткую зависимость.

3) Жёсткие связи между сервисами.
Если поменяется API одного сервиса, придётся менять код в других. В монолите это было проще, но в микросервисах приходится продумывать более гибкие механизмы, например асинхронные события через Kafka.

В следующих главах мы разберём как использовать Service Discovery и API Gateway для улучшения взаимодействия!

💡 Подведем итоги

Коты перешли с монолита на облачную микросервисную архитектуру, создав три независимых сервиса:

User Service (администрация) — регистрация и авторизация.

Order Service (рестораны) — создание заказов.

Payment Service (банк) — управление балансом.

Теперь город стал устойчивее и легче масштабировать! Но пока сервисы не умеют удобно общаться друг с другом. Как коты решат эту проблему?

📖 Продолжение следует в следующей главе!

🐰 Kafka и Spring: Почтовый голубь против почтовой службы 🌸

Olga Lugacheva — Sat, 08 Mar 2025 13:53:42 +0000

Представьте весенний лес. Солнышко светит, цветочки распускаются, птички щебечут, а зайчики 🐰 дружно решили поздравить друг друга с весной!

Но тут встаёт вопрос: как быстро доставить открытки всем друзьям?

У зайчика Санни есть два варианта:

Почтовый голубь 🕊️ – берёт письмо и летит к получателю. Правда, иногда задерживается, может устать или вообще перепутать адрес.
Супер-зайцевая почтовая служба Kafka 🚀 – распределяет все открытки в мгновение ока, без ожиданий и задержек.
Вот так же в программировании различается синхронность (когда ждём, пока голубь долетит) и асинхронность (когда всё отправляется моментально через Kafka).

Давайте поможем зайчикам разослать поздравления! 🐇✨

🕊️ Почтовый голубь: как работает синхронность

Сначала наш зайчик Санни попробовал отправлять поздравления через обычный REST-контроллер.

@RestController
@RequestMapping("/greetings")
public class GreetingController {

    @GetMapping("/{name}")
    public String sendGreeting(@PathVariable String name) {
        return "🌸 Привет, " + name + "! С первым днём весны! 🐰";
    }
}

Каждый зайчик отправляет открытку и ждёт ответа. Пока письмо не доставлено – следующий не отправить.

📬 Kafka: быстрая зайцевая почта

Санни решил создать настоящую почтовую службу для зайчиков с Kafka! Теперь сообщения отправляются в специальный "почтовый центр", где их обрабатывают супер-зайцы-почтальоны.

🛠️ Настройка Kafka в Spring Boot
Добавляем зависимости в pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

Настраиваем application.yml:

spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
    consumer:
      group-id: bunny-post-group
      auto-offset-reset: earliest
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer

Теперь наш почтовый центр готов работать! 🏡📮

🐇📩 Отправляем поздравления зайцам
Санни создал производителя (producer), который отправляет открытки в лесную почту.

@Component
public class GreetingProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public GreetingProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void sendGreeting(String name) {
        String message = "Привет, " + name + "! Весеннего тебе настроения! 🌸";
        kafkaTemplate.send("bunny-greetings", message);
    }
}

@RestController
@RequestMapping("/greetings")
public class GreetingController {

    private final GreetingProducer producer;

    public GreetingController(GreetingProducer producer) {
        this.producer = producer;
    }

    @PostMapping("/{name}")
    public String sendGreeting(@PathVariable String name) {
        producer.sendGreeting(name);
        return "Твоя открытка   для  🌸"+ name + "🌸 отправлена 🐰";
    }
}

Зайчики теперь могут отправлять поздравления без ожиданий!

🐰📬 Почтальоны-консьюмеры: доставляем открытки

Теперь создадим консьюмера (consumer) – зайцев, которые разносят открытки по лесу.

@Component
public class GreetingConsumer {

    @KafkaListener(topics = "bunny-greetings", groupId = "bunny-post-group")
    public void receiveGreeting(String message) {
        System.out.println("📩 Зайчик получил сообщение: " + message);
    }
}

Еще немного технических деталей:

Kafka должна быть запущена
Если у тебя её ещё нет, можно поднять Kafka локально через Docker:

docker-compose up -d

Один из вариантов docker-compose.yml для Kafka и Zookeeper:

version: '3'
services:
  zookeeper:
    image: wurstmeister/zookeeper:latest
    container_name: zookeeper
    ports:
      - "2181:2181"

  kafka:
    image: wurstmeister/kafka:latest
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
    depends_on:
      - zookeeper

Теперь каждый зайчик асинхронно получает своё поздравление, даже если отправителей много.

🌸Финальный результат

Теперь лесная почта работает так:

🐇 Зайчик отправляет поздравление → Оно уходит в Kafka.
🚀 Kafka мгновенно раздаёт открытки всем зайцам-почтальонам.
📩 Каждый зайчик получает сообщение, не дожидаясь других.
Всё работает параллельно и без задержек. Теперь никакие зайцы не останутся без поздравлений!

Итог

Почтовый голубь Rest (синхронность) – всё работает, но медленно.
Kafka (асинхронность) – сообщения передаются мгновенно, без ожидания!
Spring Boot + Kafka позволяют легко отправлять и получать сообщения.
Зайчики довольны, весна пришла, а поздравления разосланы! 🌷🐰

Поздравляйте друзей правильно – асинхронно с Kafka! 🎉

Hibernate-кэши: как медведи хранят запасы на зиму

Olga Lugacheva — Mon, 03 Feb 2025 18:50:27 +0000

🐻 Медведи — известные мастера организации запасов. Они прячут мёд и ягоды в разных местах, чтобы зимой не остаться голодными. Но что, если в пещере места недостаточно, а запасы устаревают? Точно так же работает кэширование в Hibernate. Медведи пользуются разными уровнями кэша, чтобы ускорить "доступ к еде" (данным), но иногда из-за устаревших запасов возникают конфликты.

1. Первый уровень кэша (Session)

🐾 Медведь организовал корзинку (Session), куда кладёт ягоды сразу, как только находит их в лесу. Если он вдруг хочет перекусить, то сначала смотрит в корзину — там ли уже есть ягода? Если нет, идёт снова в лес (запрос в базу данных).
Ключевые моменты:
Hibernate автоматически кэширует объекты в пределах сессии.
Этот кэш активен только для одного медведя (одной транзакции).
Он не делится с другими медведями.

🛠 Пример:

Session session = sessionFactory.openSession();
Product product = session.get(Product.class, 1); // Запрашиваем из корзины (кэша)
session.close(); // Корзина исчезает

Кроме get(), Hibernate может использовать load(), который создаст прокси объекта и выполнит запрос только при первом обращении к полям.

2. Второй уровень кэша (SessionFactory)

🐻 Медведи решили организовать общий склад, чтобы экономить усилия. Теперь, если мёд уже лежит на складе, они берут его оттуда, не ходя в лес.

Ключевые моменты:
Кэш на уровне SessionFactory — это как общий склад, доступный всем медведям (глобальный кэш для всех сессий).
Этот кэш доступен для всех медведей (всех транзакций).
Требует настройки внешних инструментов (EHCache, Infinispan).
Но! Если ягоды испортились, а никто не проверил, это может привести к проблемам (устаревшие данные).

🛠 Пример:

<hibernate-configuration>
    <property name="hibernate.cache.use_second_level_cache">true</property>
    <property name="hibernate.cache.region.factory_class">org.hibernate.cache.ehcache.EhCacheRegionFactory</property>
</hibernate-configuration>

Кейс 1:

// Медведь 1
Session session1 = sessionFactory.openSession();
Transaction tx1 = session1.beginTransaction();
Product product1 = session1.get(Product.class, 1);
product1.setName("Fresh Honey");
session1.update(product1);
tx1.commit();
session1.close();

// Медведь 2
Session session2 = sessionFactory.openSession();
Product product2 = session2.get(Product.class, 1); // Увидит старые данные!
System.out.println(product2.getName()); // Старое значение
session2.close();

Решение:

Используйте механизм инвалидации на уровне SessionFactory , чтобы изменения стали доступны .

sessionFactory.getCache().evict(Product.class, 1); // Удаляем старую версию объекта

Кейс 2: медведи хранят слишком много мёда, из-за чего склад переполняется и возникает проблема нехватки памяти.

Решение: настройте стратегию очистки (eviction) в зависимости от потребностей. Используйте внешние кэш-менеджеры, например EHCache, Infinispan, или Redis.

Пример настройки EHCache:

<cache name="com.example.Product" 
       maxEntriesLocalHeap="1000" 
       timeToLiveSeconds="3600" />

Кейс3: медведи работают в кластере (распределённая архитектура), но данные кэша устаревают из-за отсутствия синхронизации.

Решение:

Используйте распределённые кэши, такие как Infinispan или Hazelcast.
Настройте синхронизацию:

hibernate.cache.region.factory_class = org.infinispan.hibernate.cache.v60.InfinispanRegionFactory
hibernate.infinispan.statistics = true

Кейс4: фантомные данные (добавленные записи не видны в результате кэшированного запроса). Два медведя работают с одной и той же доской задач. Один медведь завершает задачу и вычёркивает её из списка.
Второй медведь пытается выполнить задачу, которая уже вычеркнута, но видит старый список (фантомные данные).

Решение: включите обновление кэша при вставке новых данных.

sessionFactory.getCache().evictQueryRegion("ProductQuery");

3. Запросы кэша (Query Cache)

🐻 Иногда медведи помнят не только запасы, но и "списки", где указано, сколько ягод нужно собрать с каждого куста. Этот механизм позволяет кэшировать результаты запросов.

🛠 Пример:

Query query = session.createQuery("FROM Product WHERE category = :category");
query.setCacheable(true); // Включаем кэширование для запроса
query.setParameter("category", "honey");
List<Product> products = query.list();

4. Когда медведям лучше не пользоваться кэшами

🐻 Если медведи пытаются запастись всем подряд, это может привести к хаосу. Некоторые данные проще запрашивать из леса напрямую (базы данных), чем поддерживать их свежесть в кэше.

Примеры:

Часто меняющиеся данные.
Ограниченная память на складе.

Вывод

🐾 Для кратковременных запасов — корзины (Session).
🐾 Для долгосрочных — склады (Second Level Cache).
🐾 Для списка задач — записи о кустах (Query Cache).
Но они помнят, что любые запасы требуют правильного управления и проверки, иначе последствия могут быть катастрофическими.

Медведи научились использовать кэши эффективно, будь как медведи!

🦊 Блокчейн и смарт-контракты: как лисички научились честно менять орешки 💰

Olga Lugacheva — Mon, 03 Feb 2025 18:41:42 +0000

🏗 Что такое блокчейн?

Представь, что у тебя есть деревня лис, и каждый лис любит менять орешки и ягоды.

📖 У лисов есть волшебный журнал — если кто-то обменял орешек на ягоду, все об этом записывают.

✅ НО! Записи нельзя подделать или стереть.
✅ Если один лис врёт — все остальные это видят и игнорируют обманщика.

📌 Это и есть блокчейн — честная система, где все сделки записаны и защищены.

💰 Как лисы используют блокчейн?

Лисёнок Рикки даёт 3 орешка Лисичке Лили.

Все лисы записывают: "Рикки → Лили: 3 орешка".
Запись навсегда остаётся в журнале (блокчейне).
Если кто-то попытается подделать журнал — другие лисы это заметят!
📌 Так работает блокчейн: честные сделки без обмана!

🤖 Что такое смарт-контракты?

Смарт-контракт — это умное правило, записанное в коде, которое выполняется автоматически.

Представь ларёк для лис:

Лис кладёт 2 орешка в коробку.
Если в коробке 2 орешка — он получает ягоду.
Если нет — ягоды не будет.
📌 Это и есть смарт-контракт — программа, которая проверяет условия и выполняет их сама.

🖥 Пример блокчейна с лисами на Java

Теперь давай создадим блокчейн, где лисы обменивают орешки, и добавим в него смарт-контракт, который проверяет сделки.

1️⃣ Создаём блокчейн

import java.util.ArrayList;
import java.util.List;

class Block {
    String transaction;
    int previousHash;
    int hash;

    public Block(String transaction, int previousHash) {
        this.transaction = transaction;
        this.previousHash = previousHash;
        this.hash = transaction.hashCode() + previousHash;  // Простая хеш-функция
    }
}

class Blockchain {
    List<Block> chain = new ArrayList<>();

    public Blockchain() {
        chain.add(new Block("Генезис-блок", 0));  // Первый блок
    }

    public void addTransaction(String transaction) {
        Block previousBlock = chain.get(chain.size() - 1);
        Block newBlock = new Block(transaction, previousBlock.hash);
        chain.add(newBlock);
    }

    public void printBlockchain() {
        for (Block block : chain) {
            System.out.println("Транзакция: " + block.transaction);
            System.out.println("Хеш блока: " + block.hash);
            System.out.println("Предыдущий хеш: " + block.previousHash);
            System.out.println("----------------------");
        }
    }
}

2️⃣ Добавляем смарт-контракт

Теперь создадим смарт-контракт, который проверяет сделки лис.

class SmartContract {
    private int foxNuts;
    private int requiredNuts;

    public SmartContract(int foxNuts, int requiredNuts) {
        this.foxNuts = foxNuts;
        this.requiredNuts = requiredNuts;
    }

    public void executeContract() {
        if (foxNuts >= requiredNuts) {
            System.out.println("✅ Орехов хватает! Выдаю ягоду! 🍓");
        } else {
            System.out.println("❌ Орехов мало! Ягоды нет. 😢");
        }
    }
}

3️⃣ Запускаем всю систему

Теперь мы объединяем блокчейн и смарт-контракты!

public class FoxBlockchain {
    public static void main(String[] args) {
        // Создаём блокчейн для лис
        Blockchain blockchain = new Blockchain();
        blockchain.addTransaction("🦊 Лисёнок Рикки → Лили: 3 орешка");
        blockchain.addTransaction("🦊 Лили → Бобби: 2 орешка");

        blockchain.printBlockchain();  // Выводим всю цепочку

        // Проверяем смарт-контракт
        SmartContract contract = new SmartContract(3, 2);  // У лиса 3 ореха, нужно 2
        contract.executeContract();  // Выполняем контракт
    }
}

Вывод

✔ Блокчейн — это журнал записей, который никто не может подделать.
✔ Смарт-контракты — это автоматические правила, которые выполняются сами.
✔ Теперь лисы не ссорятся, ведь все записи честные! 🦊✨

Транзакционные приключения плюшевой семьи медведей

Olga Lugacheva — Sun, 19 Jan 2025 19:55:18 +0000

Представьте: уютный магазин игрушек, которым заправляют медведи, где полки ломятся от ярких мячиков, машинок и кубиков. Но что-то пошло не так: мишки начинают толкаться, игрушки пропадают прямо из лап, а корзины странным образом заполняются несогласованными товарами. Настоящий хаос!

И вот в самый разгар беспорядка появляется семья мудрых плюшевых медведей. У каждого есть своя задача: кто-то проверяет остатки, кто-то расставляет игрушки, а кто-то бдительно следит, чтобы мячики не исчезали с полок без разрешения. Вместе они превращают беспорядочный магазин в образец идеального управления.

Что же они сделали? Как справились с конфликтами? И как им удалось навести порядок? Давайте разберёмся вместе, заглянув в закулисье их магазина – мир транзакций, блокировок и многоверсионности.

Часть 1. MVCC — как магазин управляет версиями игрушек

Магазин использует механизм MVCC (многоверсионный контроль параллелизма), чтобы покупатели могли одновременно рассматривать игрушки.
Идея проста: магазин создаёт "снимки" состояния полок для каждого покупателя. Если кто-то меняет игрушку, другие всё ещё видят её в том виде, в каком она была на момент их входа.

Например, если Папа взял мяч:

-- Папа берет мяч (создается новая версия строки)
BEGIN;
UPDATE toys SET stock = stock - 1 WHERE toy_name = 'мяч';

-- Мама начинает транзакцию позже, но видит старую версию
BEGIN;
SELECT stock FROM toys WHERE toy_name = 'мяч';
-- Магазин возвращает количество, актуальное для момента входа Мамы
COMMIT;

-- Папа подтверждает свою покупку
COMMIT;

Такой подход гарантирует, что все покупатели получают последовательные данные, даже если кто-то меняет игрушки.

Часть 2. Уровни изоляции: как покупатели взаимодействуют с полками

READ COMMITTED

Медвежонок Тедди решил взять с полки мяч и положить его в свою корзину. В это время другой Медведь проверяет, сколько мячей осталось на полке.

Медвежонок начинает забирать мяч:

BEGIN;
-- Тедди забирает мяч
UPDATE toys
SET stock = stock - 1
WHERE toy_name = 'мяч';
COMMIT;

Второй Медведь смотрит на остаток:

SELECT stock
FROM toys
WHERE toy_name = 'мяч';

На уровне READ COMMITTED второй Медведь увидит обновлённый остаток только после завершения транзакции Тедди. До этого он увидит старые данные.

REPEATABLE READ

Любопытный Медведь начал считать, сколько кукол на полке. Он открыл транзакцию, чтобы убедиться, что данные останутся неизменными, пока он работает, даже если другие медведи вносят изменения:

Любопытный Медведь начал считать:

BEGIN;
-- Посчитать кукол
SELECT stock
FROM toys
WHERE toy_name = 'кукла';

В это время другой медведь добавляет кукол:

BEGIN;
-- Другой медведь пополняет запас кукол
UPDATE toys
SET stock = stock + 5
WHERE toy_name = 'кукла';
COMMIT;

На уровне REPEATABLE READ Любопытный Медведь не увидит изменений до окончания своей транзакции. Его "снимок" данных остаётся неизменным.

SERIALIZABLE

Папа Медведь, главный управляющий, решил навести полный порядок. Он гарантировал, что все операции выполняются последовательно, как будто они происходят одна за другой:

Папа Медведь управляет процессом:

BEGIN;
-- Зарезервировать игрушки для специального заказа
SELECT *  
FROM toys  
WHERE toy_name = 'поезд'  
FOR UPDATE;  

-- Обновить остаток  
UPDATE toys  
SET stock = stock - 1  
WHERE toy_name = 'поезд';  
COMMIT;

Если другой медведь пытается взять поезд, пока идёт транзакция Папы Медведя, он видит блокировку:

BEGIN;
-- Попытка зарезервировать тот же поезд
SELECT *  
FROM toys  
WHERE toy_name = 'поезд'  
FOR UPDATE; -- Это заблокируется, пока не завершится транзакция Папы Медведя

На уровне SERIALIZABLE Папа Медведь обеспечивает строгую последовательность. Никаких неожиданностей и фантомных записей.

Часть 3. Как блокировки помогают навести порядок

1. Блокировки на уровне таблицы

Представьте, что медведь вешает на всю полку табличку: «Не трогать, пока я считаю игрушки». Это пример блокировки на уровне таблицы.

PostgreSQL поддерживает несколько режимов таких блокировок, например:

ACCESS SHARE — используется для чтения (SELECT). Другие медведи могут тоже читать, но менять ничего нельзя.
ACCESS EXCLUSIVE — полная блокировка: никто не может ни читать, ни изменять таблицу.

-- Заблокировать таблицу orders для чтения
LOCK TABLE orders IN ACCESS SHARE MODE;

-- Заблокировать таблицу для любых операций
LOCK TABLE orders IN ACCESS EXCLUSIVE MODE;

Эта блокировка полезна при миграциях или массовых обновлениях данных.

2. Блокировки на уровне строк

Блокировки на уровне строк используются для изолирования изменений конкретных записей. Например:

SELECT ... FOR UPDATE — блокирует строки для обновления.
SELECT ... FOR SHARE — блокирует строки для чтения другими транзакциями, чтобы избежать их изменения.

Однажды Медвежонок Тедди захотел зарезервировать редкую головоломку. Чтобы никто другой не смог её взять, он использовал явную блокировку:
Тедди заблокировал головоломку:

BEGIN;
-- Заблокировать головоломку
SELECT *  
FROM toys  
WHERE toy_name = 'головоломка'  
FOR UPDATE;  

-- Обновить остаток  
UPDATE toys  
SET stock = stock - 1  
WHERE toy_name = 'головоломка';  
COMMIT;

Другой медведь видит блокировку:

BEGIN;
-- Эта попытка заблокируется, пока Тедди не завершит транзакцию
SELECT *  
FROM toys  
WHERE toy_name = 'головоломка'  
FOR UPDATE;

Блокировки на уровне строк используются для изолирования изменений конкретных записей. Блокировка гарантирует, что только Тедди может работать с головоломкой, пока не завершится его транзакция.

3. Блокировки на уровне страниц

Если медведи разбивают полки на секции (например, по 10 игрушек в каждой), они могут заблокировать только одну секцию.

PostgreSQL автоматически использует блокировки на уровне страниц для оптимизации. Например, при обновлении нескольких строк в одной странице памяти, блокировка применяется к этой странице.

Эти блокировки редко используются явно разработчиками, но они важны для производительности.

Часть 4. Как магазин справляется с блокировками

Иногда покупатели начинают слишком долго думать, из-за чего магазин блокируется. Это происходит, если:

Мёртвая блокировка (Deadlock) — один покупатель ждёт другого.
Зависшие транзакции — покупатели забывают оплатить покупки.
Магазин борется с этими проблемами:

Deadlock Timeout
Если покупатели ждут друг друга, магазин завершает одну из транзакций.

SET deadlock_timeout = '5s';

Idle Transaction Timeout
Если покупатель завис в процессе, магазин завершает его транзакцию:

SET idle_in_transaction_session_timeout = '10s';

Ограничение подключений
Чтобы магазин не переполнился, он ограничивает число покупателей:

SET max_connections = 100;

Пример мёртвой блокировки:

-- Папа блокирует игрушку
BEGIN;
SELECT * FROM toys WHERE toy_name = 'мяч' FOR UPDATE;

-- Мама блокирует другую игрушку
BEGIN;
SELECT * FROM toys WHERE toy_name = 'кубик' FOR UPDATE;

-- Папа пытается взять кубик, но ждёт Мамину транзакцию
SELECT * FROM toys WHERE toy_name = 'кубик' FOR UPDATE;

-- Мама пытается взять мяч, но ждёт Папину транзакцию
SELECT * FROM toys WHERE toy_name = 'мяч' FOR UPDATE;

-- Магазин определяет мёртвую блокировку и завершает одну из транзакций

Так магазин предотвращает зависания и даёт покупателям завершить свои действия.

Весь этот рассказ о магазине игрушек помогает понять, как транзакции и блокировки в PostgreSQL работают за кулисами. Управление игрушками – это как управление данными в базе: чтобы всё было в порядке, важно следить за очередями, фиксировать изменения и предотвращать конфликты.

Если у вас много покупателей, убедитесь, что ваш магазин настроен правильно:

Настраивайте блокировки так, чтобы покупатели не путались. Например, блокируйте полку с редкой игрушкой, пока её выбирают.
Следите за взаимоблокировками, чтобы никто не остался у кассы с пустыми руками.
И помните: хорошо настроенный магазин всегда доставляет радость своим посетителям – точно так же, как продуманная база данных работает эффективно и стабильно.

Повторяем материал

Сценарий:
Ваша транзакция обновляет данные в таблице orders и вставляет данные в таблицу payments.
Во время выполнения транзакции другой пользователь пытается прочитать данные из таблицы orders, а третий пользователь выполняет обновление в таблице products.

Задачи:
1) Объясните, как уровень изоляции транзакций в PostgreSQL (READ COMMITTED, REPEATABLE READ, SERIALIZABLE)
влияет на поведение вашей транзакции и на доступ к таблицам для других пользователей.
2) Что произойдет, если транзакция вашего приложения выполнит SELECT ... FOR UPDATE на записи в таблице orders?
Как это повлияет на параллельные запросы других пользователей?
3) Какие проблемы, связанные с параллелизмом (например, грязное чтение, фантомные записи, потерянные обновления),
могут возникнуть в зависимости от выбранного уровня изоляции, и как PostgreSQL предотвращает их?

1. Влияние уровня изоляции на поведение транзакции и доступ к таблицам

1. READ COMMITTED:
Описание: Каждая операция внутри транзакции видит только подтвержденные изменения, сделанные другими транзакциями.
Эффект:
Другой пользователь, читающий таблицу orders, увидит изменения только после фиксации вашей транзакции.
Обновление в таблице products, выполняемое третьим пользователем, не будет заблокировано вашей транзакцией, так как products не участвует в вашей транзакции.
2. REPEATABLE READ:
Описание: Транзакция видит снимок базы данных, актуальный на момент её начала. Изменения других транзакций игнорируются до фиксации.
Эффект:
Другой пользователь не увидит изменений в orders, даже если вы завершите изменения, пока ваша транзакция активна.
Обновления в products третьим пользователем также будут возможны, так как products не блокируется.
3. SERIALIZABLE:
Описание: Этот уровень изоляции эмулирует выполнение транзакций последовательно. PostgreSQL предотвращает любые конфликты, которые могли бы нарушить согласованность данных.
Эффект:
Другой пользователь, читающий таблицу orders, может быть заблокирован до завершения вашей транзакции.
Обновления в products также могут быть заблокированы, если PostgreSQL определит потенциальный конфликт с вашей транзакцией.

2. SELECT ... FOR UPDATE на таблице orders

Ваша транзакция блокирует строки таблицы orders, выбранные запросом SELECT ... FOR UPDATE.
Другие транзакции:

Не смогут обновить заблокированные строки до завершения вашей транзакции.
Могут читать данные из таблицы, но не блокированные строки. Эффект: Параллельные запросы на чтение: Работают нормально, если не включают заблокированные строки. Параллельные запросы на обновление: Заблокированы до фиксации или отката вашей транзакции.

3. Проблемы параллелизма и их предотвращение в PostgreSQL

1. Грязное чтение (Dirty Reads):
Проблема: Транзакция читает данные, которые ещё не зафиксированы.
Предотвращение: Исключается на уровне READ COMMITTED и выше.
2. Неповторяющееся чтение (Non-Repeatable Reads):
Проблема: Данные, прочитанные в начале транзакции, могут измениться до её завершения.
Предотвращение: Исключается на уровне REPEATABLE READ и выше.
3. Фантомные записи (Phantom Reads):
Проблема: Данные, соответствующие критерию запроса, могут измениться (например, новые строки появляются).
Предотвращение: Исключается на уровне SERIALIZABLE.
4. Потерянные обновления (Lost Updates):
Проблема: Два пользователя обновляют одни и те же данные, и одно из изменений теряется.
Предотвращение: PostgreSQL использует блокировки (например, SELECT ... FOR UPDATE).

Волшебные скоупы: Как Spring организует работу бинов

Olga Lugacheva — Sun, 12 Jan 2025 13:07:06 +0000

В мастерской Spring трудились умелые и старательные помощники — бины. Каждый из них был наделен своей уникальной задачей: кто-то создавал игрушки, кто-то сортировал конфеты, а кто-то выращивал яркие цветы.

Чтобы работа мастерской была упорядоченной и эффективной, для бинов были установлены четкие правила — скоупы. Эти правила определяли, как долго бины могли существовать и сколько экземпляров одного вида должно быть создано одновременно. Благодаря этим волшебным рамкам мастерская работала слаженно и надежно.

Прототип (Prototype): Ежик-пекарь

Ежик-пекарь каждый раз, когда кто-то заказывает пирог, создает новый пирог с уникальными ингредиентами.

Ежик: "Каждый хочет свой вкус! Поэтому я создаю свежий пирог для каждого заказа."

@Component
@Scope("prototype")
public class Hedgehog {
    public void bakePie() {
        System.out.println("Пеку пирог!");
    }
}

Так работает scope prototype в Spring: каждый раз при запросе нового объекта создается уникальный экземпляр бина. Это полезно, когда требуется изолированная логика для каждого использования.

Например:

В приложении есть бин, который генерирует отчет для каждого пользователя:

@Component
@Scope("prototype")
public class ReportGenerator {
    public Report generate(String userData) {
        // Генерация уникального отчета
        return new Report(userData);
    }
}

Каждый вызов context.getBean(ReportGenerator.class) создаст новый экземпляр. Это удобно для обработки уникальных данных в многопользовательских системах.

Request: Кролик-раздатчик морковки

Кролик-раздатчик объясняет своим помощникам:

"Для каждого гостя, который приходит на поляну, я собираю морковку. Но как только гость уходит, корзинка возвращается ко мне."

@Component
@Scope("request")
public class Rabbit {
    public void giveCarrot() {
        System.out.println("Вот твоя морковка!");
    }
}

Request scope в Spring означает, что один бин создается на каждый HTTP-запрос. После завершения запроса бин уничтожается.

Пример использования:
Представьте, что в веб-приложении у вас есть компонент для сбора данных пользователя:

@Component
@Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserCart {
    private List<Item> items = new ArrayList<>();

    public void addItem(Item item) {
        items.add(item);
    }

    public List<Item> getItems() {
        return items;
    }
}

Каждому запросу пользователя выделяется уникальная корзина, которая "живёт" только в рамках обработки HTTP-запроса. Как только запрос завершён, бин удаляется, освобождая память.

Сравнение Prototype и Request в реальной разработке:

Prototype: используется для задач, требующих уникальных экземпляров при каждом вызове, например, в тестировании, генерации уникальных данных, обработки изолированных задач.
Request: полезен в веб-приложениях для обеспечения изоляции данных между запросами пользователей. Например, корзина покупок, данные аутентификации или временные токены.
Разница в подходах:

Prototype может использоваться в любых контекстах, включая консольные приложения.
Request строго привязан к веб-контексту, поскольку зависит от HTTP-запросов.

Singleton: Боб-строитель

Боб-строитель работает в лесу и строит плотину для всех. Он говорит:

"Я один, и я построю что угодно, сколько бы животных ко мне ни пришло!"

Это означает, что у нас всегда будет один и тот же экземпляр объекта, к которому обращаются все клиенты. И каждый раз приходит один и тот же Боб. Ему не нужно было клонироваться или исчезать. Так он трудился день за днем.

@Component
@Scope("singleton")
public class Bob {
    public void buildDam() {
        System.out.println("Строю плотину!");
    }
}

Singleton — это скоуп по умолчанию в Spring. Один экземпляр бина создается на всё время работы приложения. Такой бин используется, когда объект должен быть общим ресурсом для всех компонентов приложения.

Пример использования:
Предположим, у вас есть компонент для логирования:

@Component
public class Logger {
    public void log(String message) {
        System.out.println(message);
    }
}

Этот бин создается один раз, и все компоненты приложения используют его для записи логов. Это эффективно и экономит память.

Применение:

Логирование
Работа с базой данных через пул соединений
Управление кэшами

Session: Медвежонок Мед

Медвежонок варит мед для каждого гостя, который пришел в его дом. Он говорит:

"Пока ты у меня в гостях, я заботюсь о твоем горшочке. Но как только ты уходишь, твой медовый горшочек исчезает."

@Component
@Scope("session")
public class Bear {
    public void makeHoney() {
        System.out.println("Варю мед для тебя!");
    }
}

Скоуп session в Spring означает, что бин существует столько, сколько длится HTTP-сессия пользователя.

Техническое пояснение:
Этот скоуп используется в веб-приложениях, чтобы привязать объект к конкретной сессии пользователя. Когда сессия завершается, бин уничтожается.

Пример использования:
Представьте, что у вас есть компонент для хранения данных авторизации пользователя:

@Component
@Scope(value = WebApplicationContext.SCOPE_SESSION, proxyMode = ScopedProxyMode.TARGET_CLASS)
public class UserSession {
    private String userId;

    public void setUserId(String userId) {
        this.userId = userId;
    }

    public String getUserId() {
        return userId;
    }
}

Этот бин создается для каждого пользователя, пока длится его сессия.

Применение:

Хранение данных пользователя (например, авторизации, предпочтений)
Управление сессионными токенами

Application: Филин Фил

Филин Фил каждый вечер рассказывает сказки всем лесным жителям. Он говорит:

"Моя сказка одна на весь лес. Все приходят ко мне слушать, и всем хватает!"

@Component
@Scope("application")
public class Owl {
    public void shareWisdom() {
        System.out.println("Мудрость дня: бобры строят лучшие плотины.");
    }
}

Скоуп application означает, что бин создается один раз на всё приложение, но отличается от singleton тем, что он используется только в контексте веб-приложений.

Этот скоуп аналогичен singleton, но управляется веб-контекстом. Он используется для компонентов, которые должны быть доступны на уровне всего приложения.

Пример использования:
Например, бин для хранения глобальных настроек:

@Component
@Scope(value = WebApplicationContext.SCOPE_APPLICATION)
public class AppSettings {
    private String appName = "ForestApp";

    public String getAppName() {
        return appName;
    }
}

Этот бин создается один раз и доступен всем.

Применение:

Конфигурация приложения
Глобальные настройки
Кэш данных, общий для всех пользователей

Сравнение всех скоупов Spring

Scope	Жизненный цикл	Пример использования
Singleton	Всё время работы приложения	Логирование, работа с базами данных
Prototype	Новый объект при каждом вызове	Генерация отчётов, тестирование
Request	Один HTTP-запрос	Корзина покупок, временные данные
Session	Вся HTTP-сессия пользователя	Данные авторизации, настройки пользователя
Application	Всё время работы приложения	Глобальные настройки, кэш на уровне приложения

Когда что использовать?
Singleton — для общих, не изменяющихся ресурсов.
Prototype — для изолированных задач, уникальных данных.
Request — для временных данных в рамках одного запроса.
Session — для данных, которые нужно хранить между запросами одного пользователя.
Application — для глобальных данных, которые используют все пользователи.

Праздничные гонки Санты: Волшебство многопоточности Java

Olga Lugacheva — Tue, 31 Dec 2024 16:27:48 +0000

В далёком снежном королевстве, где сугробы сияют, словно бриллианты, а звёзды нашёптывают сказки, Санта готовился к самой волшебной ночи года. Его фабрика гудела, как гигантский музыкальный инструмент: эльфы бегали с коробками, игрушки сверкали разноцветными красками, а колокольчики звенели с каждым новым готовым подарком.

Но волшебство оказалось под угрозой.

"Слишком много игрушек! Лента переполнена!" — жаловался главный эльф-производитель.
"Мы не успеваем упаковывать!" — вторил ему эльф-упаковщик.

Санта задумался: "Как помочь моим эльфам? Они стараются изо всех сил, но без магии не обойтись".

Первая магия: Синхронизация

Санта обратился к заклинанию, известному как synchronized. Оно создавало защитный барьер, чтобы эльфы не толкались и не путались при работе с общей лентой.

"Теперь только один из вас может класть или забирать игрушки одновременно", — объяснил Санта.

Вот как это выглядело:

class SantaFactory {
    private final Queue<String> conveyorBelt = new LinkedList<>();
    private final int MAX_CAPACITY = 10;

    public void produce(String toy) throws InterruptedException {
        synchronized (conveyorBelt) {
            while (conveyorBelt.size() == MAX_CAPACITY) {
                System.out.println("Производитель ждёт: лента заполнена!");
                conveyorBelt.wait(); // Производитель ждёт, пока появится место
            }
            conveyorBelt.add(toy);
            System.out.println("Игрушка произведена: " + toy);
            conveyorBelt.notifyAll(); // Уведомляем упаковщиков о новой игрушке
        }
    }

    public void consume() throws InterruptedException {
        synchronized (conveyorBelt) {
            while (conveyorBelt.isEmpty()) {
                System.out.println("Потребитель ждёт: игрушек нет!");
                conveyorBelt.wait(); // Упаковщик ждёт, пока появится игрушка
            }
            String toy = conveyorBelt.poll();
            System.out.println("Игрушка упакована: " + toy);
            conveyorBelt.notifyAll(); // Уведомляем производителей о свободном месте
        }
    }
}

Магические свойства wait и notifyAll:

wait(): Усыпляет поток, пока условие (например, пустая лента) не станет ложным.
notifyAll(): Будит всех ожидающих потоков, чтобы они проверили, могут ли продолжить работу.

Вторая магия: BlockingQueue

Санта понял, что эльфы часто забывали вызывать notifyAll, и это создавало задержки. Тогда он применил магический инструмент — BlockingQueue, который сам заботился о потоках.

BlockingQueue делает следующее:

Если лента заполнена, производитель автоматически ждёт.
Если лента пуста, упаковщик сам понимает, что нужно подождать.

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;

class SantaFactoryBlocking {
    private final BlockingQueue<String> conveyorBelt = new ArrayBlockingQueue<>(10);

    public void produce(String toy) throws InterruptedException {
        conveyorBelt.put(toy); // Если лента заполнена, поток автоматически ждёт
        System.out.println("Игрушка произведена: " + toy);
    }

    public void consume() throws InterruptedException {
        String toy = conveyorBelt.take(); // Если лента пуста, поток автоматически ждёт
        System.out.println("Игрушка упакована: " + toy);
    }
}

Третья магия: Executors и пул потоков

Чтобы эльфы не уставали, Санта создал магический инструмент — пул потоков. Теперь каждый эльф выполнял свою задачу, и их количество автоматически регулировалось.

"Эльфы больше не будут бегать друг за другом, всё работает плавно," — радовался Санта.

Пример кода:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class SantaRaceWithExecutors {
    public static void main(String[] args) {
        SantaFactoryBlocking factory = new SantaFactoryBlocking();
        ExecutorService executor = Executors.newFixedThreadPool(4); // 4 эльфа

        // Запускаем 2 производителя
        for (int i = 1; i <= 2; i++) {
            executor.submit(() -> {
                try {
                    for (int j = 1; j <= 20; j++) {
                        factory.produce("Игрушка #" + j);
                        Thread.sleep(100); // Производство занимает время
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        // Запускаем 2 упаковщика
        for (int i = 1; i <= 2; i++) {
            executor.submit(() -> {
                try {
                    for (int j = 1; j <= 20; j++) {
                        factory.consume();
                        Thread.sleep(150); // Упаковка занимает время
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        executor.shutdown(); // Завершаем работу после выполнения всех задач
    }
}

Магические свойства Executors:

newFixedThreadPool(n): Создаёт пул из n потоков, которые будут повторно использоваться.
submit(task): Запускает задачу в одном из потоков.
shutdown(): Завершает выполнение после завершения всех задач.

Четвёртая магия: CompletableFuture

На последнем этапе Санта добавил немного дополнительного волшебства: теперь эльфы работали асинхронно, что ускоряло процесс.

import java.util.concurrent.CompletableFuture;

public class SantaRaceWithCompletableFuture {
    public static void main(String[] args) {
        SantaFactoryBlocking factory = new SantaFactoryBlocking();

        CompletableFuture.runAsync(() -> {
            try {
                for (int i = 1; i <= 20; i++) {
                    factory.produce("Игрушка #" + i);
                    Thread.sleep(100); // Производство занимает время
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        CompletableFuture.runAsync(() -> {
            try {
                for (int i = 1; i <= 20; i++) {
                    factory.consume();
                    Thread.sleep(150); // Упаковка занимает время
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
    }
}

Магические свойства CompletableFuture:

Асинхронность: задачи выполняются в фоновом потоке, не блокируя основной поток.
Простота использования: не нужно вручную управлять потоками.

Новый год спасён!

Когда последние игрушки были упакованы, Санта с радостью вздохнул. "Эльфы, вы проделали невероятную работу. Магия многопоточности сделала нас не только быстрее, но и счастливее!"

И теперь каждую ночь под Новый год Санта рассказывает своим помощникам сказку о том, как многопоточность спасла праздник.

✨ С Новым годом, друзья! 🎄

"Тайны Pawsgresville: Дело об исчезнувших данных". Идексы Postgres.

Olga Lugacheva — Mon, 23 Dec 2024 11:46:29 +0000

В оживлённом городе Pawsgresville, где данные текли, как реки, и порой так же непредсказуемо исчезали, работал частный сыщик по имени Биллометр Би-Tри, или просто B-Tree. Его офис, утопающий в бумагах и запахе дешёвого кофе, всегда был полон клиентов, жаждущих разгадать загадки своих запросов: найти потерянные данные, упорядочить списки или вычислить хитроумные диапазоны. Но однажды на пороге его офиса появилась проблема, способная перевернуть весь порядок в городе.

Глава 1. Таинственное исчезновение

В тот день в офис вошла нервная сиамская кошка с лэптопом в лапах. Её звали Лайка, и она владела небольшим архивом запросов. Её проблема была сложной: «Мой поиск перестал работать. Я ввожу ‘%tractor%’, а результаты находят всё, что угодно, кроме нужного!»

B-Tree прищурился и задумчиво посмотрел на экран. «Так-так. LIKE с ведущим процентом, говорите? Вы использовали индекс?»

«Конечно! У меня стоит обычный B-Tree индекс, но он будто игнорируется!»

«Вот в чём дело, мадам, — сказал детектив, — ваш запрос с ведущим ‘%’ вынуждает систему сканировать всю таблицу. Индексы B-Tree просто не предназначены для таких трюков. Но не волнуйтесь, у меня есть решение. Это работа для профессора GIN.»

Глава 2. GIN и загадка словаря

В соседнем районе, среди пыльных книжных полок, жил профессор GIN. Он знал всё о полнотекстовом поиске и индексах, которые могли справиться с задачами, перед которыми B-Tree пасовал.

«Профессор GIN, нам нужна ваша помощь!» — заявил B-Tree, ввалившись в библиотеку. Лайка, прижав уши, следовала за ним.

«Что у вас на этот раз?» — спросил GIN, глядя поверх очков.

«LIKE с ведущим процентом. И обычный B-Tree не справляется.»

Профессор склонился над лэптопом, перебирая данные. «Вам нужен GIN-индекс или хотя бы trigram extension. Смотрите, — он открыл словарь на слове ‘трактор’ и показал, как индекс можно использовать для разбиения слов на подстроки. — GIN отлично работает, если вы часто ищете фрагменты слов. Но помните: если данных слишком мало, накладные расходы на создание такого индекса могут быть не оправданы.»

CREATE INDEX idx_content ON documents USING gin(to_tsvector('english', content));
SELECT * FROM documents WHERE to_tsvector('english', content) @@ to_tsquery('tractor');

Лайка выглядела впечатлённой. «Такой индекс точно решит мою проблему?»

«В большинстве случаев, да. Но есть нюанс: Если вам придётся часто добавлять или обновлять данные, мой индекс может замедлить операции. Это моя слабость. А для сложных пространственных задач есть ещё один эксперт.»

Глава 3. Заговор полигона

В другой части города произошла кража. Билл и GIN направились к старому знакомому — мистеру GIST. Этот рыжий кот, известный своим свободным характером, обитал в мастерской на окраине города, где возился с геометрическими запросами и сложными структурами данных. Карта геометрических данных оказалась повреждена.
«Я слышал, вам нужны индексы для хитрых диапазонов?» — спросил GIST, подкручивая свои усы.
«Именно так. Кто-то украл часть данных о полигонах, — сказал Билл. — Нам нужно найти все области, которые пересекаются с этим прямоугольником!Нам нужны индексы, которые могут обрабатывать запросы вроде ‘найти все записи внутри определённого квадрата или диапазона значений.’»

GiST кивнул и создал геометрический индекс:

CREATE INDEX idx_map ON locations USING gist(location);
SELECT * FROM locations WHERE location && 'BOX(1 1, 5 5)'::box;

— Ваш случай особый, — добавил GiST. — Мне хорошо даются сложные данные, но для простых диапазонов, таких как даты, я могу быть медленнее.

Глава 4. BRIN и огромные архивы

Тем временем в архиве городского регистратора застряли поисковики. База данных была огромной, и никто не мог найти документы за определённый месяц.
— У нас есть BRIN! — предложил архивариус. — Он отлично справляется с большими данными, которые хранятся в упорядоченном виде.

BRIN подошёл к задаче с минималистичным подходом:

CREATE INDEX idx_events ON events USING brin(event_date);
SELECT * FROM events WHERE event_date BETWEEN '2024-01-01' AND '2024-01-31';

— Я экономлю много места, — объяснил BRIN, — но если данные не упорядочены, моя эффективность падает.

Глава 5. Загадка логических связок

Тем временем детектив Биллометр Би-Три столкнулся с новой задачей. Клиент попросил найти данные с двумя условиями:

SELECT * FROM users WHERE age = 25 AND city = 'Saint-Pawsburg';

— Ну что ж, детективы, за дело! — сказал Билл.

B-Tree любит, чтобы всё было по порядку. Для этого в таблице был индекс:

CREATE INDEX idx_users_age_city ON users (age, city);

— Отлично! — сказал B-Tree. — Я знаю, как искать: сначала найду всех, у кого age = 25, а потом проверю city = 'Saint-Pawsburg'.

Но тут прилетел другой запрос:

SELECT * FROM users WHERE city = 'Saint-Pawsburg' AND age = 25;

Билл вздохнул:
— Порядок в индексе важен! У меня сначала age, а потом city. Если ты начнёшь с city, я не смогу сразу сузить круг поиска.
Клиент ушел, но вернулся с новым запросом
— Мне нужны записи, где возраст = 25 ИЛИ город = 'Saint-Pawsburg'.

Билл задумался. Он знал, что его индекс поддерживает запросы с AND, но с OR всё сложнее. Если у тебя есть индексы только на возраст и на город, то Postgres объединяет результаты:

SELECT * FROM users WHERE age = 25 OR city = 'Saint-Pawsburg';

Но это может быть медленно. OR-запросы редко работают хорошо с одним индексом. Придётся работать тяжело: я сначала найду всех с age = 25, а потом добавлю тех, у кого city = 'Saint-Pawsburg'.
— Лучший способ ускорить такие запросы — отдельные на каждую колонку индексы
CREATE INDEX idx_age ON users (age);
CREATE INDEX idx_city ON users (city);
или пересмотр условий, — посоветовал Билл.

На следующий день Билл отправился в Зал Планировщиков.

Глава 6. Планировщик и великий анализ

Это было место, где великий Query Planner обучал новичков искусству составления планов выполнения запросов. Он стоял у доски, показывая разницу между Index Scan и Sequential Scan, а детектив сидел в заднем ряду, внимательно слушая. Планировщик решал, использовать ли индекс вообще.

— Ваш запрос, — сказал он Биллу, — слишком неэффективен. Данные малы, поэтому последовательный обход таблицы будет быстрее.

Поняв это, Билл стал чаще советовать клиентам использовать EXPLAIN ANALYZE, чтобы понять, как Postgres выбирает планы:

EXPLAIN ANALYZE SELECT * FROM users WHERE age = 25;

Это помогало увидеть, использует ли запрос индекс и почему.

«Планировщик — тот ещё хитрец, — говорил Query Planner, — он выбирает путь, который считает оптимальным, но не всегда угадывает. Индекс может не использоваться, если таблица маленькая или если фильтр слишком общий. А ещё есть VACUUM. Без регулярной уборки таблицы индексы могут терять свою эффективность.»
Билл кивнул. Он знал, что VACUUM — это тот самый процесс, который убирает мёртвые строки и держит данные в форме. «Значит, уборка так же важна, как и хороший план.»

Глава 7: Секреты подземелий VACUUM

Когда детектив B-Tree думал, что дело близится к завершению, в офис постучался новый клиент. Это был пушистый белый кот по имени Vacuum, известный в Пушгресвиле как мастер уборки данных.

— «Детектив B-Tree, я заметил странности в подземных хранилищах данных. Кажется, там накопилось слишком много мусора, и я не могу эффективно выполнять свою работу!»

B-Tree приподнял шляпу, задумавшись:

— «Расскажите подробнее, Vacuum. Вы ведь тот самый, кто заботится о чистоте таблиц и удалении устаревших строк?»

Vacuum кивнул.

— «Верно. Но в последнее время в таблицах Пушгресвиля полно мёртвых строк, оставшихся после DELETE и UPDATE запросов. Их никто не убирает, и это мешает индексам работать быстро. А ещё... кажется, некоторым индексам нужна моя помощь, чтобы оставаться компактными.»

— «Компактность... это звучит серьёзно,» — пробормотал B-Tree.

Vacuum разложил карту:

Обычный VACUUM: он очищает мёртвые строки, но не возвращает место операционной системе.
VACUUM FULL: он полностью реорганизует таблицы, возвращая свободное пространство системе. Правда, это требует блокировки таблиц.
Автовакуум: работает в фоновом режиме, но иногда не справляется, если нагрузка слишком велика или настройки сервера не оптимальны.
— «Это как убирать мусор с улиц. Если делать это нерегулярно, движение по городу замедляется,» — объяснил Vacuum.

B-Tree вспомнил, как недавно планировщик запросов жаловался на Sequential Scan, который с каждым днём становился всё медленнее.

— «Значит, ты не только убираешь мусор, но и помогаешь индексам оставаться эффективными?»

Vacuum улыбнулся.

— «Точно! Без меня GIN и GiST начинают страдать, ведь их размеры увеличиваются, а поиск становится медленнее. А BRIN вообще может потерять свой смысл, если я не буду поддерживать порядок в данных.»

Полезные советы для расследований

Индексы работают быстрее, если запросы учитывают порядок столбцов. Например, если индекс CREATE INDEX idx_users_age_city ON users (age, city), то запросы вроде WHERE age = ... AND city = ... будут работать эффективно. А вот WHERE city = ... AND age = ... могут быть медленнее.
Сложные условия с OR редко эффективно используют индексы.
Если много OR-условий, попробуйте переписать запросы или создать несколько индексов.
Для LIKE лучше использовать pg_trgm.
Подключите расширение:
CREATE EXTENSION pg_trgm; CREATE INDEX idx_users_name_trgm ON users USING gin (name gin_trgm_ops);
Это ускорит запросы вроде LIKE '%подстрока%'.
Проверяйте запросы с помощью EXPLAIN ANALYZE. Оно покажет, что делает планировщик, и подскажет, как улучшить запрос.
Не злоупотребляйте индексами. Они ускоряют чтение, но замедляют вставку и обновление данных.

Когда использовать какой индекс?

Каждый тип индекса в PostgreSQL — мастер в своём деле:
B-Tree — универсальный детектив. Поиск равенства и диапазонов, сортировка.
GIN — быстрый эксперт по множественным совпадениям. Полнотекстовый поиск, JSONB, массивы.
GiST — аналитик сложных структур. Геометрия, диапазоны, сложные типы данных.
BRIN — экономный, но эффективный на огромных данных. Очень большие таблицы, упорядоченные данные.

Так в Клубе Индексов каждый запрос находил своего детектива. А Pawsgresvill оставался самым быстрым и умным городом баз данных, потому что его жители всегда соблюдали порядок в индексе и использовали подходящие инструменты. 🕵️‍♂️

🐾 Hibernate Zoo: Путеводитель по языкам запросов в мире данных 🐾

Olga Lugacheva — Fri, 13 Dec 2024 15:28:54 +0000

Добро пожаловать в Hibernate Zoo! Сегодня мы прогуляемся по волшебному миру запросов к базе данных. Разные животные-запросы здесь выполняют свои задачи: кто-то собирает информацию, кто-то фильтрует, а кто-то умело жонглирует данными. Давайте познакомимся с ними поближе и разберем, как они работают! 🚀

🐘 Hibernate Native SQL: Слон-гигант

Слон – могучий зверь! Он может поднимать огромные запросы на "родном языке" базы данных — SQL.

@Repository
public interface AnimalRepository extends JpaRepository<Animal, Long> {

    @Query(value = "SELECT * FROM animals WHERE type = :type", nativeQuery = true)
    List<Animal> findByTypeNative(@Param("type") String type);
}

Пример использования:

List<Animal> mammals = animalRepository.findByTypeNative("mammal");
mammals.forEach(System.out::println);

👉 Слон тут явно говорит: "Дай мне всех млекопитающих!"
nativeQuery = true говорит Hibernate, что это настоящий SQL.

💡 Плюсы: Мощный и прямой доступ к базе. Это удобно, если нужно выполнять запросы, которые сложно выразить через JPQL, Criteria API или другие подходы.
😅 Минусы: Не самый гибкий зверь, может быть тяжеловесным для сложных структур. Синтаксис запроса зависит от конкретной базы данных (например, PostgreSQL или MySQL).

🐆 EntityManager Dynamic Queries: Гепард-исследователь

Гепард любит скорость и динамику. Он строит запросы прямо "на ходу".

Пример:

String query = "SELECT a FROM Animal a WHERE a.type = :type";
List<Animal> mammals = entityManager.createQuery(query)
                                     .setParameter("type", "mammal")
                                     .getResultList();

👉 Гепард бежит к млекопитающим со скоростью молнии!

💡 Плюсы: Гибкость.
😅 Минусы: Нужно следить за строками, иначе гепард запутается.

🐻 Criteria API: Медведь-строитель

Медведь основателен и любит все делать по порядку. Он строит запросы как дом: кирпичик за кирпичиком.

Пример:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Animal> query = cb.createQuery(Animal.class);
Root<Animal> animal = query.from(Animal.class);
query.select(animal).where(cb.equal(animal.get("type"), "mammal"));

List<Animal> mammals = entityManager.createQuery(query).getResultList();

👉 Медведь основательно ищет млекопитающих, не пропуская ни одного.

💡 Плюсы: Гибкость и типобезопасность.
😅 Минусы: Немного громоздко.

🐦 JPQL: Попугай-болтун

Попугай говорит на языке сущностей! Он похож на SQL, но более дружелюбный к объектам.

Пример:

List<Animal> mammals = entityManager.createQuery(
    "SELECT a FROM Animal a WHERE a.type = 'mammal'", Animal.class)
    .getResultList();

👉 Попугай просто болтает с базой: "Привет, дай мне всех млекопитающих!"

💡 Плюсы: Похож на SQL, но для сущностей.
😅 Минусы: Меньше возможностей, чем у медведя .

🐥 Spring Data Query Methods: Цыплёнок-помощник

Цыплёнок любит простоту. Вы пишете метод в репозитории, а он сам знает, как искать данные.

Пример:

List<Animal> findByType(String type);

👉 Цыплёнок тут как бы говорит: "Ты скажи, что нужно искать, а я найду!"

💡 Плюсы: Очень просто!
😅 Минусы: Только для стандартных задач.

🦊 Spring Data Specifications: Лис-стратег

Лис умён и хитёр. Он комбинирует запросы как пазлы.

Пример:

Specification<Animal> isMammal = (root, query, cb) -> cb.equal(root.get("type"), "mammal");
List<Animal> mammals = animalRepository.findAll(isMammal);

👉 Лис создаёт стратегию, чтобы найти млекопитающих.

💡 Плюсы: Комбинация условий.
😅 Минусы: Требует опыта.

🐾

Какого зверя выбрать?

Если нужен доступ на уровне SQL – зови слона.
Если любишь гибкость и типобезопасность – позови медведя.
Если хочешь что-то быстро построить – зови гепарда.
Если хочешь простоты – доверься цыплёнку.
Если хочешь гибкость стратегий – позови лиса.
Каждое животное уникально и подходит для своей задачи. В Hibernate Zoo вы найдете друзей на любой случай! 🐾

Полезные ссылочки

Hibernate

Spring Data JPA

Persistence Context в Hibernate Zoo: путешествие объекта по жизненным состояниям

Olga Lugacheva — Fri, 06 Dec 2024 16:52:36 +0000

Добро пожаловать в Hibernate Zoo! Сегодня у нас увлекательное представление: встречайте Persistence Context! Этот веселый и усердный приятель — супергерой для ваших данных, сидящих в базе, и ловкач, который умеет управляться с хитрыми связями и объектами. Чтобы почувствовать себя настоящим исследователем, не забудьте надеть виртуальные очки Java, а код мы с вами закидаем прямо по ходу экскурсии.

Секреты за кулисами: что же такое Persistence Context?

Persistence Context — это, если уж говорить серьезно, некий контейнер для всех объектов, которые Hibernate отслеживает во время работы с базой данных. И как только вы начинаете транзакцию, Persistence Context тут как тут. Он наблюдает за каждым объектом, кэширует их, чтобы при повторных запросах не дергать базу данных понапрасну, и управляет состоянием всех сущностей.
Представьте его как упитанного енота с корзиной: он обходит все ваши объекты, с радостью добавляет их в корзинку, запоминает и хранит при себе, пока не закончится транзакция. А потом (бац!) он сохранит их в базе данных одним движением.

Жизненные стадии объектов в контексте персистенции Hibernate
В мире Hibernate объект может переходить из одного состояния в другое, и это критически важно для управления его жизненным циклом. Понимание этих стадий помогает эффективно управлять сохранением, обновлением и удалением данных. Итак, представьте, что ваш объект путешествует по четырём разным стадиям, как по уровням компьютерной игры.

Transient (Гость у ворот)

Когда объект только что создан и ещё не привязан ни к базе данных, ни к Hibernate-сессии, он находится в состоянии Transient (или "Переходное состояние"). Hibernate о нём ничего не знает, и, следовательно, он не будет сохранён в базе данных до тех пор, пока не попадёт под управление контекста персистенции.

Пример: Кот Бублик только появился

Cat cat = new Cat("Бублик", "серый");  // Transient
System.out.println("Имя кота: " + cat.getName());

Persistent (Взяли под крылышко)

Теперь, когда вы решили, что ваш кот (или другой объект) заслуживает внимания и должен быть сохранён в базе, вы вызываете метод save() или persist(). После этого он становится persistent и Hibernate начинает за ним следить. Все изменения, которые вы будете вносить в этот объект, будут автоматически отслеживаться и сохранены в базе данных при закрытии транзакции.

Пример: Бублик обрел дом в базе

Session session = sessionFactory.openSession();
session.beginTransaction();

Cat cat = new Cat("Бублик", "серый");
session.save(cat);  // Теперь кот стал persistent
cat.setColor("белый");  // Изменили цвет

session.getTransaction().commit();
session.close();

Теперь кот Бублик persistent: Hibernate "запомнил" его и, когда вы закрываете транзакцию, изменения (например, смена цвета на белый) автоматически сохраняются в базе данных.

Detached (Бублик без надзора)

Когда сессия Hibernate закрывается (например, после вызова session.close()), объекты, которые были persistent, становятся detached. Это значит, что теперь они больше не отслеживаются Hibernate и никакие изменения, которые вы внесете в них, не будут автоматически сохранены.

Представьте, что кот Бублик убежал на улицу, и теперь Hibernate за ним больше не присматривает.

Пример: Бублик уходит, но он уже не в контексте

Session session = sessionFactory.openSession();
session.beginTransaction();

Cat cat = session.get(Cat.class, 1);  // Кот уже есть в базе и стал persistent
session.getTransaction().commit();
session.close();  // Теперь он detached

cat.setColor("черный");  // Изменение цвета больше не отслеживается Hibernate

После закрытия сессии кот Бублик больше не находится под контролем Hibernate. Его статус detached, и если мы изменим его цвет на "черный", это не сохранится в базе данных.

Вернуть кота обратно в Hibernate
Чтобы снова привязать объект к контексту персистенции, можно использовать метод merge()

Session newSession = sessionFactory.openSession();
newSession.beginTransaction();

Cat mergedCat = (Cat) newSession.merge(cat);  // Бублик снова под контролем Hibernate
mergedCat.setColor("рыжий");  // Hibernate снова отслеживает изменения

newSession.getTransaction().commit();
newSession.close();

После вызова merge() Hibernate снова начинает следить за Бубликом, и теперь все изменения будут сохранены.

Removed

Когда вы решаете, что объект больше не нужен в базе данных, вы можете пометить его для удаления с помощью session.delete(). Это переводит объект в состояние Removed. Объект ещё может существовать в памяти, но как только транзакция завершится, он исчезнет из базы данных. Итак, наш герой отправился вновь на поиски приключений.

Пример: Путь на свободу

Session session = sessionFactory.openSession();
session.beginTransaction();

Cat cat = session.get(Cat.class, 1);  // Бублик под контролем Hibernate
session.delete(cat);  // Пометили на удаление

session.getTransaction().commit();  // Бублик удалён из базы
session.close();

Как только мы вызвали delete(), объект стал Removed. После завершения транзакции Бублик будет удалён из базы данных навсегда.

Схема переходов состояний в Hibernate

Чтобы наглядно представить переходы между состояниями, можно использовать следующую схему:

Transient→ Persistent: объект сохраняется в базе данных с помощью session.save() или session.persist().
Persistent→ Detached: сессия закрывается, и объект выходит из-под контроля Hibernate.
Detached→ Persistent: объект снова привязывается к Hibernate с помощью session.merge() или session.update().
Persistent→ Removed: объект помечается для удаления с помощью session.delete().

Методы для Управления Жизненным Циклом Объектов в Hibernate
Hibernate предоставляет множество методов для управления состояниями объектов. От создания до удаления, каждый метод влияет на объект и его связь с базой данных через Persistence Context. Давайте разберемся в каждом методе, их особенностях, типичных ошибках и полезных примерах.

Приведем основные методы Hibernate для управления жизненным циклом

save()
Назначение:
Сохраняет объект в базу данных, переводя его из Transient в Persistent.

Ключевые особенности:

Генерирует SQL-запрос INSERT, добавляя объект в базу.
Возвращает идентификатор (id), сгенерированный для объекта.
Не требует, чтобы объект уже существовал в базе

Cat murzik = new Cat("Мурзик", "серый"); // Transient
session.save(murzik); // Теперь murzik — Persistent

Типичная ошибка:
Попытка вызвать save() для объекта с уже установленным идентификатором может вызвать ошибки из-за конфликта id.

persist()
Назначение:
Также переводит объект в состояние Persistent.

Отличие от save():

persist() ничего не возвращает.
Используется только для объектов, которые не имеют идентификатора (новые).
Пример:

Cat barsik = new Cat("Барсик", "рыжий");
session.persist(barsik); // Добавлен в Persistence Context

Типичная ошибка:
persist() нельзя использовать для объектов, находящихся в состоянии Detached.

update()
Назначение:
Привязывает объект в состоянии Detached к текущей сессии и переводит его в Persistent.

Пример:

session.close(); // Объект стал Detached
session = factory.openSession();
session.update(detachedCat); // Привязываем обратно

merge()
Назначение:
Объединяет изменения в объекте в состоянии Detached с текущим состоянием в Persistence Context.

Пример:

Cat detachedCat = session.get(Cat.class, 1);
session.close(); // Detached
detachedCat.setColor("белый");

session = factory.openSession();
session.merge(detachedCat); // Объединяет изменения с базой

Отличие от update():

merge() создаёт новый объект, если Detached-объект уже существует в Persistence Context.
Это делает merge() более безопасным.

delete()
Назначение:
Удаляет объект из базы данных и переводит его в состояние Removed.

Пример:

session.delete(murzik); // Удаляет объект из базы

Особенность:
После удаления объект остаётся в памяти, но больше не привязан к Persistence Context.

flush()
Назначение:
Принудительно синхронизирует состояние Persistence Context с базой данных.

Пример:

session.save(cat);
session.flush(); // Все изменения записаны в базу

Типичная ошибка:
Если между flush() и commit() произойдёт ошибка, база останется несинхронизированной.

saveOrUpdate()
Назначение:
Сохраняет новый объект или обновляет существующий.

Пример:

Cat cat = new Cat("Барсик", "рыжий");
cat.setId(1); // Если id существует, объект будет обновлён
session.saveOrUpdate(cat);

Особенность:

Используйте этот метод, если не уверены, новый объект или уже существующий.
Но это может вызвать больше запросов, чем нужно.

clear()
Назначение:
Очищает Persistence Context, удаляя все объекты из него.

Пример:

session.clear(); // Все объекты становятся Detached

Типичная ошибка:
После clear() нельзя обращаться к объектам, ожидая, что они останутся Persistent.

detach()
Назначение:
Превращает объект в состояние Detached, исключая его из Persistence Context.

Пример:

session.detach(cat); // Теперь cat — Detached

close()
Назначение:
Закрывает сессию Hibernate, делая все объекты Detached.

Пример: session.close();

Сложности и Типичные Ошибки

Ошибка при использовании update(): Если объект с таким же идентификатором уже существует в Persistence Context, Hibernate выбросит исключение. Решение: Использовать merge(), если не уверены в состоянии объекта.

Потеря данных из-за flush():
Если вызвать flush() перед commit(), изменения могут записаться в базу, но не будут зафиксированы.
Решение:
Использовать commit() сразу после flush().

Дублирование при использовании save():
Если вы вызываете save() для объекта с установленным id, это может привести к нарушению уникальности.
Решение:
Проверяйте, существует ли объект, прежде чем вызывать save().
Ленивая загрузка (LazyInitializationException):
Ошибка возникает, если вы пытаетесь получить доступ к связанным объектам после закрытия сессии.
Решение:
Использовать fetch=FetchType.EAGER.
Загружать данные заранее с помощью JOIN FETCH.

Путешествие объектов в Hibernate Zoo — это захватывающее приключение, где на каждом этапе Бублик и его друзья попадают в разные состояния и взаимодействуют с базой данных через Persistence Context. В начале они свободны, как птицы (или коты!), потом попадают под строгий надзор, выходят в свободное плавание и, в конце концов, могут покинуть этот зоопарк навсегда.

Как подружить котиков, слонов и китов: тестирование Spring-приложений с Testcontainers 🐱🐘🐋

Olga Lugacheva — Sun, 01 Dec 2024 06:19:23 +0000

Когда речь идет о тестировании Spring-приложений, нам часто приходится решать, как эмулировать реальные компоненты и внешние сервисы, чтобы тесты были как можно более похожи на реальную работу приложения. Но вот где всё становится интересным: мы будем использовать Testcontainers для эмуляции наших зависимостей и контейнеров. И это будет весело! Приготовьтесь познакомиться с котиками, слонами и китами, которые помогут вам на пути к стабильным и качественным тестам!

Что такое Testcontainers и зачем нам котики, слоны и киты?

Testcontainers — это библиотека для Java, которая позволяет запускать Docker-контейнеры прямо в процессе тестирования. Вместо того чтобы подключаться к реальным базам данных или сервисам, Testcontainers запускает их в контейнерах, предоставляя вам возможность легко тестировать приложение с реальными зависимостями, не загромождая вашу среду.

Котики 🐱 — это, конечно же, ваше приложение, которое мы тестируем.
Слоны 🐘 — это ваша база данных PostgreSQL, которую мы будем эмулировать в контейнере.
Киты 🐋 — это Docker, который управляет всеми контейнерами и помогает нашему приложению взаимодействовать с ними.
Testcontainers — это инструмент, который помогает запускать временные контейнеры для тестов. С его помощью мы можем использовать контейнеры с базой данных или другими сервисами, чтобы протестировать наше приложение.

Почему Docker нам нужен?
Docker позволяет создать временную базу данных, не занимая много места на компьютере.
Testcontainers автоматически запустит нужную нам базу данных для тестов, а после тестов удалит её.
Вместо того чтобы вручную настраивать PostgreSQL, мы просто говорим Testcontainers: "Запусти контейнер с PostgreSQL", и всё готово!
Важно: Чтобы все это работало, у тебя должен быть установлен Docker. Без него контейнеры не смогут работать.

Установка Docker (если у тебя его нет)

Скачай и установи Docker Desktop с официального сайта.
Запусти Docker.

Настройка окружения с котиками и слонами

Для начала давайте настроим PostgreSQL (слона) с помощью Testcontainers. Представьте, что котик сидит за компьютером и готовится к работе, а слон подготавливает базу данных для тестов.
В нашем проекте нам нужны следующие зависимости:

<dependencies>
    <!-- Testcontainers для Docker -->
      <dependency>
          <groupId>org.testcontainers</groupId>
          <artifactId>postgresql</artifactId>
          <scope>test</scope>
      </dependency>

    <!-- Spring Boot Starter Web для работы с контроллерами -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <!-- PostgreSQL Driver -->
    <dependency>
        <groupId>org.postgresql</groupId>
        <artifactId>postgresql</artifactId>
    </dependency>

    <!-- Spring Boot Test для тестирования -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

    <dependency>
       <groupId>org.testcontainers</groupId>
       <artifactId>junit-jupiter</artifactId>
       <scope>test</scope>
    </dependency>
</dependencies>

Мы создадим контроллер, который будет управлять запросами к базе данных. Например, пусть это будет контроллер, который работает с сущностью Kitten , и при этом взаимодействует с базой данных PostgreSQL.

Пример контроллера:

@RestController
@RequestMapping("/kittens")
public class KittenController {

    private final KittenService kittenService;

    @Autowired
    public KittenController(KittenService kittenService) {
        this.kittenService = kittenService;
    }

    @GetMapping
    public List<Kitten> getKittens() {
        return kittenService.getAllKittens();
    }

    @PostMapping
    public Kitten addKitten(@RequestBody Kitten kitten) {
        return kittenService.addKitten(kitten);
    }
}

Как видите, контроллер использует сервис KittenService, который, в свою очередь, обращается к репозиторию для получения и сохранения данных. А теперь давайте проверим, как все это работает, настроив окружение с Testcontainers.

Использование Testcontainers для запуска PostgreSQL

Чтобы эмулировать PostgreSQL в контейнере, нам нужно создать контейнер с PostgreSQL и указать его параметры для использования в тестах. Вместо того чтобы подключаться к реальной базе данных, мы запустим ее прямо в Docker-контейнере.

@Testcontainers
public class KittenControllerTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:14")
            .withDatabaseName("test_db")
            .withUsername("test")
            .withPassword("test");

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @BeforeAll
    public static void beforeAll() {
        postgres.start(); //стартуем контейнер с Postgres
    }

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    void testGetKittens() {
        // Тестируем GET-запрос на получение котиков
        ResponseEntity<List<Kitten>> response = restTemplate.exchange("/kittens", HttpMethod.GET, null,
                new ParameterizedTypeReference<List<Kitten>>() {});
        assertEquals(HttpStatus.OK, response.getStatusCode());
        assertTrue(response.getBody().size() > 0);
    }

    @Test
    void testAddKitten() {
        // Тестируем POST-запрос на добавление нового котика
        Kitten newKitten = new Kitten("Fluffy", 1);
        ResponseEntity<Kitten> response = restTemplate.postForEntity("/kittens", newKitten, Kitten.class);
        assertEquals(HttpStatus.CREATED, response.getStatusCode());
        assertNotNull(response.getBody().getId());
    }
}

Что происходит?

@Container: Аннотация от Testcontainers, которая говорит, что postgres — это контейнер, который нужно запустить перед тестами.
PostgreSQLContainer<?>: Специальный класс для создания контейнера PostgreSQL.
"postgres:14": Используем образ PostgreSQL версии 14.
withDatabaseName("test_db"): Создаем базу данных с именем test_db.
withUsername("test") и withPassword("test"): Указываем логин и пароль для подключения к базе данных.
Таким образом, этот код создает контейнер PostgreSQL, который автоматически запускается перед тестами и завершает работу после их окончания. Это исключает необходимость устанавливать PostgreSQL вручную.

Аннотация @DynamicPropertySource

@DynamicPropertySource
static void configureProperties(DynamicPropertyRegistry registry) {
    registry.add("spring.datasource.url", postgres::getJdbcUrl);
    registry.add("spring.datasource.username", postgres::getUsername);
    registry.add("spring.datasource.password", postgres::getPassword);
}

Аннотация @DynamicPropertySource, которая позволяет динамически задавать свойства приложения во время тестов.
DynamicPropertyRegistry registry: Хранилище для свойств, которое обновляется значениями из контейнера.
Зачем это нужно? Spring Boot-приложения используют application.properties для настройки подключения к базе данных. Вместо того чтобы прописывать их вручную, мы берем данные из контейнера:

spring.datasource.url: Получаем URL подключения к базе данных из контейнера.
spring.datasource.username и spring.datasource.password: Используем логин и пароль контейнера PostgreSQL.
Таким образом, приложение во время тестов подключается к базе данных в контейнере, а не к реальной базе данных. Это позволяет тестировать приложение в чистом изолированном окружении.

Как котики и слоны дружат с китами

Docker (кит) помогает нашему приложению Spring Boot запускать контейнеры с PostgreSQL (слон) для тестирования. Все это происходит благодаря Testcontainers, который автоматически запускает контейнеры и делает их доступными для вашего теста.

Когда вы запускаете тесты, Testcontainers подготавливает PostgreSQL контейнер с правильными настройками, а ваше приложение (котик) может без проблем взаимодействовать с ним. В этом процессе Docker (кит) берет на себя управление контейнерами и гарантирует, что все работает корректно.

Преимущества использования Testcontainers

Изоляция тестов. Каждый тест запускает новый контейнер, что позволяет гарантировать чистоту данных и изоляцию.
Реальные данные. Вы тестируете ваше приложение на реальных сервисах и базах данных, а не на мокаемых компонентах.
Легкость в настройке. Не нужно вручную устанавливать и конфигурировать базы данных — все автоматически настраивается в контейнерах.

Заключение: Как котики, слоны и киты помогли нам

В итоге, когда котики (Spring Boot приложение), слоны (PostgreSQL) и киты (Docker) объединяются в одном тесте, мы получаем мощную комбинацию для тестирования реальных зависимостей. Вы больше не зависите от локальных баз данных или мока, а можете быть уверены, что ваше приложение будет работать с настоящими сервисами и базами данных. Это и есть секрет успеха качественных тестов в современных Spring-приложениях!

Теперь у нас есть полностью настроенное тестирование с Testcontainers, и все работает как часы, благодаря котикам, слонам и китам! 🐱🐘🐋