Pesquisei a documentação/Javadocs do Apache Ignite 3.1.0. Há algumas diferenças importantes em relação às hipóteses iniciais: Ignite 3 mudou bastante o modelo — deixou de ser centrado em IgniteCache e passou a ser centrado em tables + SQL + transactions + compute.

1. Como se cria uma ligação thin client em Ignite 3.1?

Em Ignite 3.1 não é:

java
ClientConnectorAddress addr = ...
Ignition.startClient(...)

Isso é o modelo do Ignite 2.x.

Em 3.1, a dependência é:

xml
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-client</artifactId>
    <version>3.1.0</version>
</dependency>

E a ligação é:

java
import org.apache.ignite.client.IgniteClient;

IgniteClient client = IgniteClient.builder()
    .addresses("host:10800")
    .build();

Ou, de preferência:

java
try (IgniteClient client = IgniteClient.builder()
        .addresses(
            "ignite-1:10800",
            "ignite-2:10800",
            "ignite-3:10800")
        .build()) {

    // ...
}

É exatamente o exemplo oficial. Em Ignite 3 todos os clientes externos são “thin”: não entram na topologia, não armazenam dados e não executam jobs localmente. (Apache Ignite)

Portanto, sim: o teu IgniteConfig.java de 291 linhas provavelmente desaparece quase todo. Os antigos IgniteConfiguration, discovery SPI, communication SPI, collision SPI, etc. eram configuração de um nó Ignite embebido. Um cliente 3.1 limita-se essencialmente à configuração da ligação:

java
@Bean(destroyMethod = "close")
public IgniteClient igniteClient() {
    return IgniteClient.builder()
        .addresses("ignite-1:10800", "ignite-2:10800")
        .connectTimeout(5_000)
        .operationTimeout(3_000)
        .build();
}

O builder suporta, entre outras coisas, timeout de ligação, heartbeat, operation timeout, reconnect e retry policy. (Apache Ignite)

Classificação: IgniteSpringBean + IgniteConfiguration + SPIs → TROCA DIRECTA, mas por um objeto muito mais simples: IgniteClient.

---

2. O que um thin client pode fazer em 3.1?

Este é o ponto que mais muda a migração.

O interface público Ignite em 3.1 expõe essencialmente:

text
catalog()
cluster()
compute()
sql()
tables()
transactions()

E IgniteClient extends Ignite. Não aparecem cache(), services(), events(), semaphore() etc. (Apache Ignite)

A tua matriz fica assim:

Código/conceito 2.x	Ignite 3.1	Categoria	Substituição
client.cache("FX_RATE")	❌ não existe	REIMAGINE	client.tables().table("FX_RATE") + KeyValueView/RecordView
cache.lock(key)	❌ não existe	REIMAGINE	transaction locking
client.compute().call(...)	⚠️ API mudou	TROCA DIRECTA	client.compute().execute(...)
client.events()	❌ não existe	REIMAGINE	event channels/sinks; atualmente log sink
client.services()	❌ não existe	REIMAGINE	normalmente Compute / serviço externo
client.semaphore()	❌ não existe	REIMAGINE	coordenação via outro mecanismo ou tabela+transação
client.cluster().nodes()	✅ existe	TROCA DIRECTA	praticamente igual
client.getOrCreateCache(...)	❌ cache API desapareceu	REIMAGINE	catalog().createTable(...) / CREATE TABLE IF NOT EXISTS

client.cache("FX_RATE")

Não existe cache() em Ignite 3. O equivalente conceptual passa a ser uma table.

Por exemplo:

java
Table table = client.tables().table("FX_RATE");

KeyValueView<String, FxRate> rates =
    table.keyValueView(String.class, FxRate.class);

FxRate rate = rates.get(null, "EUR/USD");

Ou com tuples:

java
KeyValueView<Tuple, Tuple> rates =
    client.tables()
        .table("FX_RATE")
        .keyValueView();

O próprio guia explica KeyValueView como uma visão dictionary/key-value sobre uma table. (Apache Ignite)

Portanto, uma chamada do género:

java
ignite.cache("FX_RATE").get(key);

vira aproximadamente:

java
ignite.tables()
    .table("FX_RATE")
    .keyValueView(Key.class, FxRate.class)
    .get(null, key);

Não é uma simples renomeação de classe porque cache → table é uma mudança de modelo. Eu marcaria REIMAGINE, mesmo que muitos DAOs acabem por ter uma tradução bastante mecânica.

---

client.cache("FX_RATE").lock(key)

Não existe API de lock explícito equivalente.

Mas Ignite 3 tem locking transacional. A documentação diz que todas as transações read-write adquirem locks no primeiro acesso de leitura/escrita e mantêm-nos até commit() ou rollback(). As read-write transactions são SERIALIZABLE. (Apache Ignite)

Assim, se o código antigo era:

java
Lock lock = cache.lock(key);
lock.lock();
try {
    FxRate rate = cache.get(key);
    ...
    cache.put(key, rate);
} finally {
    lock.unlock();
}

o desenho 3.1 seria aproximadamente:

java
client.transactions().runInTransaction(tx -> {
    FxRate rate = rates.get(tx, key);

    // altera rate

    rates.put(tx, key, rate);
});

A primeira operação dentro da read-write transaction adquire os locks relevantes, e estes ficam presos à transação. (Apache Ignite)

A diferença fundamental é:

text
Ignite 2:
explicit distributed Lock independente da transação

Ignite 3:
locking como parte da transaction

Logo: REIMAGINE.

Se o lock() atual for usado apenas para proteger um get → modify → put, a migração é relativamente limpa. Se estiver a ser usado como um mutex distribuído genérico para proteger código que não tem nada a ver com dados Ignite, então é uma mudança arquitetural maior.

---

client.compute().call(...)

Compute existe no thin client 3.1, mas a API é diferente.

Agora é baseada em JobTarget + JobDescriptor:

java
String result = client.compute().execute(
    JobTarget.anyNode(client.cluster().nodes()),
    JobDescriptor.builder(MyJob.class)
        .resultClass(String.class)
        .build(),
    argument
);

Há execute(), executeAsync(), submitAsync(), execução colocada com dados e MapReduce. (Apache Ignite)

Um detalhe importante: código enviado por um thin client tem de estar disponível/deployed nos nós onde vai executar; o Ignite 3 tem deployment units para esse efeito. (Apache Ignite)

Eu classificaria:

compute().call() → TROCA DIRECTA, mas com adaptação significativa de API:

text
call(...)
    ↓
compute().execute(JobTarget, JobDescriptor, arg)

---

client.events()

Não existe.

Ignite 3 tem Events, mas não é o antigo IgniteEvents programático. Os eventos são configurados cluster-wide através de event channels e enviados para sinks.

Na versão 3.1 a documentação diz explicitamente que o único sink disponível é log. (Apache Ignite)

Exemplo administrativo:

text
cluster config update \
  ignite.eventlog.channels.exampleChannel.events=["USER_AUTHENTICATION_SUCCESS"]

Portanto:

java
client.events().remoteListen(...)

não tem substituição direta.

Classificação: REIMAGINE.

Se o código atual usa eventos para lógica de negócio, é especialmente importante inventariá-lo; se usa apenas para audit/monitoring/logging, provavelmente pode ser eliminado da aplicação e transferido para a configuração/observabilidade do cluster.

---

client.services()

Não existe services() na API pública do Ignite 3.1.

O Ignite 3.1 só apresenta catalog, cluster, compute, sql, tables e transactions. (Apache Ignite)

O antigo Ignite 2 tinha IgniteServices e client.services().serviceProxy(...); isso continua documentado apenas na documentação 2.x. (Apache Ignite)

Se o serviço era essencialmente:

text
cliente
   ↓
serviceProxy("PricingService")
   ↓
executar Java no cluster

o candidato natural em 3 é Compute:

text
cliente
   ↓
compute.execute(...)
   ↓
job deployed no cluster

Mas não é semanticamente equivalente a coisas como cluster singleton/service lifecycle.

Portanto: REIMAGINE.

---

client.semaphore()

Também não existe no API público 3.1.

Os distributed data structures de Ignite 2 (IgniteSemaphore, locks, atomic longs, queues, etc.) não aparecem no novo Ignite API. O Javadoc 3.1 deixa isso bastante evidente pelo conjunto muito pequeno de facades públicas. (Apache Ignite)

Portanto:

java
ignite.semaphore(...)

→ REIMAGINE.

Dependendo do uso, poderá ser substituído por:

text
tabela + transaction

se for coordenação fortemente ligada a estado persistido, ou por um mecanismo externo de coordenação se for um semaphore/mutex genérico.

---

client.cluster().nodes()

Sim. Existe exatamente em 3.1.

java
Collection<ClusterNode> nodes =
    client.cluster().nodes();

O próprio Javadoc diz que retorna os nós da logical topology. (Apache Ignite)

Aliás, o antigo:

java
ignite.clusterNodes()

está deprecated em 3.1 e o replacement oficial é precisamente:

java
ignite.cluster().nodes()

(Apache Ignite)

TROCA DIRECTA.

---

client.getOrCreateCache(...)

Não existe porque já não há caches como entidade de API.

Agora crias tables.

Em 3.1 há inclusive uma API nova:

java
client.catalog().createTable(...);

Por exemplo, a própria Javadoc mostra:

java
@Table
class Value {
    String val;
}

Table table =
    client.catalog().createTable(Integer.class, Value.class);

que gera conceptualmente:

sql
CREATE TABLE IF NOT EXISTS Value (
    id INT,
    val VARCHAR,
    PRIMARY KEY (id)
);

Também podes usar builders:

java
TableDefinition definition =
    TableDefinition.builder("FX_RATE")
        .ifNotExists()
        // columns...
        .build();

Table table = client.catalog().createTable(definition);

(Apache Ignite)

Ou simplesmente SQL:

java
client.sql().execute(
    null,
    """
    CREATE TABLE IF NOT EXISTS FX_RATE (
        PAIR VARCHAR PRIMARY KEY,
        RATE DECIMAL(20, 10)
    )
    """
);

(Apache Ignite)

Logo:

text
getOrCreateCache()
       ↓
CREATE TABLE IF NOT EXISTS
ou catalog().createTable(...)

REIMAGINE, porque tens agora um schema explícito.

---

4. Existe ignite-spring para Ignite 3.1?

Aqui há uma distinção importante.

Spring Boot + IgniteClient: SIM

Ignite 3.1 tem:

xml
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>spring-boot-starter-ignite-client</artifactId>
    <version>3.1.0</version>
</dependency>

(Maven Central)

E disponibiliza oficialmente:

java
IgniteClientAutoConfiguration

que cria um bean IgniteClient. (Apache Ignite)

As propriedades usam o prefixo:

properties
ignite.client...

porque:

java
@ConfigurationProperties(prefix="ignite.client")
class IgniteClientProperties

(Apache Ignite)

Portanto, se o problema for apenas:

“Quero que Spring Boot crie/injete o meu IgniteClient”

há TROCA DIRECTA.

---

Spring Cache (CacheManager): NÃO para Ignite 3.1

O antigo:

java
SpringCacheManager
IgniteClientSpringCacheManager

pertence à integração Ignite 2.x e trabalha sobre IgniteCache/ClientCache. A própria documentação dessa extensão fala em IgniteConfiguration, ignite-core e ignite-spring. (Apache Ignite)

Mais conclusivo: o artefacto:

text
org.apache.ignite:ignite-spring

continua com latest 2.18.0, não 3.1.0. (Maven Central)

E ignite-spring-cache-ext também não é uma implementação Ignite 3.1. (javadoc)

Há ainda uma armadilha:

xml
org.apache.ignite:ignite-spring-data-ext:3.1.0

parece ser “Ignite 3.1”, mas não é. O POM desse artefacto depende de:

xml
<artifactId>ignite-core</artifactId>
<version>2.17.0</version>

(Maven Central)

Ou seja, o 3.1.0 aí é a versão da extensão, não “compatível com Apache Ignite 3.1”.

Consequência para o JsonCacheProxyManager

Se hoje ele implementa/faz bridge:

text
Spring Cache
    ↓
IgniteClientSpringCacheManager
    ↓
ClientCache

não tens uma troca oficial pronta em Ignite 3.1.

Terás de implementar algo deste género:

text
Spring Cache API
      ↓
teu CacheManager / Cache
      ↓
IgniteClient
      ↓
Table + KeyValueView

Portanto:

JsonCacheProxyManager → REIMAGINE.

Não significa necessariamente muito código: um adapter org.springframework.cache.Cache sobre uma KeyValueView pode ser relativamente pequeno. Mas já não é uma dependência oficial que trocas no pom.xml.

---

5. O que é que @QuerySqlField virou?

A resposta é: @QuerySqlField desapareceu.

Não virou:

java
org.apache.ignite.lang.query.annotations.QuerySqlField

Essa hipótese está errada.

O @QuerySqlField pertence ao modelo Ignite 2:

java
org.apache.ignite.cache.query.annotations.QuerySqlField

onde um POJO armazenado numa cache precisava de indicar ao SQL quais os fields visíveis/indexados. (Apache Ignite)

Em Ignite 3, SQL opera sobre tables com schema explícito. Portanto, se criaste:

sql
CREATE TABLE FX_RATE (
    ID BIGINT PRIMARY KEY,
    SYMBOL VARCHAR,
    RATE DECIMAL
);

ID, SYMBOL e RATE são automaticamente colunas SQL. Não precisas de marcar cada field com @QuerySqlField.

Para schema/mapping Java, a nova package é:

java
org.apache.ignite.catalog.annotations

com:

Ignite 3 annotation	Função
@Table	define table
@Column	mapeia/configura coluna
@Id	primary key
@Index	índice
@ColumnRef	coluna utilizada por índices/colocation
@Zone	distribution zone

São exatamente as annotations presentes na Javadoc 3.1. (Apache Ignite)

Por exemplo, isto em 2.x:

java
public class FxRate {
    @QuerySqlField(index = true)
    private String symbol;

    @QuerySqlField
    private BigDecimal rate;
}

conceptualmente pode virar:

java
@Table(
    value = "FX_RATE",
    indexes = {
        @Index(
            value = "IX_FX_RATE_SYMBOL",
            columns = @ColumnRef("SYMBOL")
        )
    }
)
public class FxRate {

    @Id
    private Long id;

    @Column("SYMBOL")
    private String symbol;

    @Column("RATE")
    private BigDecimal rate;
}

O Ignite 3.1 usa estas annotations tanto para schema como para mapping; Mapper.builder(...).automap() consegue ler @Column. (Apache Ignite)

Assim, a regra de migração é essencialmente:

text
@QuerySqlField
    ↓
REMOVER

Se tinha apenas:

java
@QuerySqlField

normalmente desaparece, porque a coluna já existe no schema da table.

Se tinha:

java
@QuerySqlField(index = true)

tens de preservar a intenção através de:

java
@Index(...)

ou:

sql
CREATE INDEX ...

Portanto eu marcaria globalmente REIMAGINE, embora muitas annotations individuais sejam simplesmente REMOVER.

---

Tabela final para a tua análise de migração

Ignite 2 / código atual	Ignite 3.1	Decisão
IgniteSpringBean	IgniteClient bean	TROCA DIRECTA
IgniteConfiguration no cliente	IgniteClient.builder()	TROCA DIRECTA
Discovery/Communication/etc. SPIs no cliente	nada	REMOVER
ClientCache / IgniteCache	Table + KeyValueView/RecordView	REIMAGINE
cache.get/put	KeyValueView.get/put	TROCA DIRECTA depois de remodelar para table
cache.lock(key)	read-write transaction	REIMAGINE
compute().call(...)	compute().execute(...)	TROCA DIRECTA
events()	channels + sinks/logging	REIMAGINE
services()	sem equivalente; possivelmente Compute	REIMAGINE
semaphore()	sem equivalente	REIMAGINE
cluster().nodes()	cluster().nodes()	TROCA DIRECTA
getOrCreateCache()	catalog().createTable() / CREATE TABLE IF NOT EXISTS	REIMAGINE
SpringCacheManager	sem implementação Ignite 3.1	REIMAGINE
Spring Boot → IgniteClient bean	spring-boot-starter-ignite-client:3.1.0	TROCA DIRECTA
@QuerySqlField simples	schema/table column	REMOVER
@QuerySqlField(index=true)	@Index / CREATE INDEX	TROCA DIRECTA/REIMAGINE

A conclusão arquitetural mais importante é esta: não estás a migrar “Ignite 2 cache API → Ignite 3 cache API”. Não existe essa cache API. Estás a migrar de um Data Grid/cache-first para um modelo schema/table-first. É isso que explica porque os SPIs, ClientCache, services, semaphores, @QuerySqlField e Spring Cache deixam de ter substituições 1:1. (Apache Ignite)