Sesiones

En esta página, se describe el concepto avanzado de sesiones en Spanner, incluidas las prácticas recomendadas para las sesiones cuando se crea una biblioteca cliente, se usan las APIs de REST o RPC, o se usan las bibliotecas cliente de Google.

Una sesión proporciona un contexto para las operaciones de base de datos con el servicio de base de datos de Spanner. Una sesión se usa para ejecutar transacciones que leen, escriben o modifican datos en una base de datos de Spanner. Cada sesión se aplica a una única base de datos.

Las sesiones pueden ejecutar una o varias transacciones a la vez. Cuando se realizan varias transacciones, la sesión se denomina sesión multiplexada. Las lecturas, escrituras y consultas independientes usan una transacción de forma interna.

Administra el rendimiento de las sesiones

Las sesiones son el contexto de una operación de base de datos, por lo que la forma en que las administras afecta directamente la latencia y el uso de recursos de tu aplicación. Puedes administrar el rendimiento de las sesiones de las siguientes tres maneras:

• Usa un grupo de sesiones.
• Usa sesiones multiplexadas.
• Optimiza la configuración del canal de gRPC.

Usa un grupo de sesiones

Crear una sesión agrega latencia, ya que cada sesión nueva requiere un viaje de ida y vuelta al servicio de base de datos de Spanner. Para reducir esta latencia, usa un grupo de sesiones: una colección de sesiones disponibles que están listas para usarse. En lugar de crear una sesión para cada operación, el grupo devuelve una sesión existente y la recupera para volver a usarla después. Esto distribuye la latencia de creación de sesiones en muchas operaciones, en lugar de eliminarla por completo. El grupo almacena las sesiones existentes, devuelve el tipo de sesión adecuado cuando se solicita y limpia las sesiones no utilizadas.

Las sesiones están diseñadas para ser de larga duración, por lo que, después de que se usa una sesión para una operación de base de datos, el cliente debe devolver la sesión al grupo para su reutilización.

Usa sesiones multiplexadas

Las sesiones multiplexadas te permiten realizar varias solicitudes simultáneas en una sola sesión, lo que reduce la sobrecarga del backend y el consumo de recursos. Para obtener más información, consulta Sesiones multiplexadas.

Optimiza la configuración del canal de gRPC

Reduce la latencia de cola alta (p95/p99) causada por la congestión del canal de gRPC durante el tráfico alto ajustando el grupo de canales de gRPC. En las bibliotecas cliente compatibles, la agrupación dinámica de canales cambia automáticamente el tamaño del grupo de canales a medida que cambia la carga. Esto ayuda a reducir la latencia de cola relacionada con la congestión y a evitar el aprovisionamiento insuficiente o excesivo de canales.

Descripción general de los canales de gRPC

El cliente de Spanner usa los canales de gRPC para la comunicación. Un canal de gRPC equivale aproximadamente a una conexión TCP. Un canal de gRPC puede controlar hasta 100 solicitudes simultáneas. Esto significa que una aplicación necesitará, al menos, tantos canales de gRPC como la cantidad de solicitudes simultáneas que ejecutará la aplicación, dividida por 100.

El cliente de Spanner crea un grupo de canales de gRPC cuando lo creas.

Prácticas recomendadas para usar bibliotecas cliente de Google

A continuación, se describen las prácticas recomendadas para usar las bibliotecas cliente de Google para Spanner.

Configura la cantidad de sesiones y canales de gRPC en los grupos

La forma en que administras las sesiones y los canales de gRPC depende de la biblioteca cliente. Las bibliotecas cliente que admiten sesiones multiplexadas, como las bibliotecas cliente de Go y Java, no requieren que configures un grupo de sesiones y pueden administrar el grupo de canales de gRPC por ti a través de la agrupación dinámica de canales. Las otras bibliotecas cliente usan un grupo de sesiones con una cantidad mínima y máxima predeterminada de sesiones, y una cantidad predeterminada de canales de gRPC. Los valores predeterminados son adecuados para la mayoría de los casos. En las siguientes secciones, se describen los valores predeterminados y las opciones de configuración para cada lenguaje de programación.

MinSessions: 100
MaxSessions: 400
NumChannels: 4

MinSessions: 100
MaxSessions: 400
NumChannels: 4

// Use 16 gRPC channels instead of the default of four.
client, err := spanner.NewClient(ctx,
    "projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    option.WithGRPCConnectionPool(16),
)

client, err := spanner.NewClientWithConfig(ctx,
    "projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    spanner.ClientConfig{
        DynamicChannelPoolConfig: spanner.DynamicChannelPoolConfig{
            DCPEnabled: true,
        },
    })

SpannerOptions options =
    SpannerOptions.newBuilder()
        .setProjectId("PROJECT_ID")
        .enableDynamicChannelPool()
        .build();

SpannerOptions options =
    SpannerOptions.newBuilder()
        .setProjectId("PROJECT_ID")
        .enableDynamicChannelPool()
        .setGcpChannelPoolOptions(
            GcpChannelPoolOptions.newBuilder()
                .setMaxSize(15)
                .setMinSize(3)
                .setInitSize(5)
                // setDynamicScaling(minRpcPerChannel, maxRpcPerChannel,
                // scaleDownInterval): scale up as soon as a channel's load
                // exceeds 30 concurrent RPCs. Scale-up is event-driven, so
                // the pool grows immediately as load rises. Scale-down is
                // periodic: a channel is removed only after it stays under
                // 10 concurrent RPCs across the check that runs every 5
                // minutes.
                .setDynamicScaling(10, 30, Duration.ofMinutes(5))
                .build())
        .build();

MinSessions: 25
MaxSessions: 100

MaxChannels: 10
ConcurrentRequestsPerChannel: 25

const {Spanner} = require('@google-cloud/spanner');
    // Note: Ensure grpcGcp is initialized
const customGcpApiConfig = {
  channelPool: {
    maxSize: 20, // Overriding default 10
    maxConcurrentStreamsLowWatermark: 50 // Overriding default 25
  }
};
const spanner = new Spanner({
  'grpc.gcpApiConfig': grpcGcp.createGcpApiConfig(customGcpApiConfig)
});

MinSessions: 1
MaxSessions: 500

MinSessions: 10
MaxSessions: 100

Usa sesiones multiplexadas si la biblioteca cliente de tu lenguaje de programación las admite. Las sesiones multiplexadas no requieren ninguna configuración, y una sola sesión multiplexada puede ejecutar cualquier cantidad de transacciones simultáneas.

La cantidad de sesiones que usa tu aplicación es igual a la cantidad de transacciones simultáneas que ejecuta. Solo debes modificar la configuración predeterminada del grupo de sesiones si esperas que una sola instancia de la aplicación ejecute más transacciones simultáneas de las que puede controlar el grupo de sesiones predeterminado.

Para las aplicaciones con alta simultaneidad, se recomienda lo siguiente:

1. Establece MinSessions en la cantidad esperada de transacciones simultáneas que ejecutará un solo cliente.
2. Establece MaxSessions en la cantidad máxima de transacciones simultáneas que puede ejecutar un solo cliente.
3. Establece MinSessions=MaxSessions si la simultaneidad esperada no cambia mucho durante el ciclo de vida de la aplicación. Esto evita que el grupo de sesiones aumente o disminuya. Aumentar o reducir la escala del grupo de sesiones también consume algunos recursos.
4. Establece NumChannels en MaxSessions / 100. Un canal de gRPC puede controlar hasta 100 solicitudes de forma simultánea. Aumenta este valor si observas una latencia de cola alta (latencia p95/p99), ya que esto podría ser un indicio de congestión del canal de gRPC.

Aumentar la cantidad de sesiones activas usa recursos adicionales en el servicio de base de datos de Spanner y en la biblioteca cliente. Aumentar la cantidad de sesiones más allá de la necesidad real de la aplicación podría disminuir el rendimiento de tu sistema.

Aumenta el grupo de sesiones en lugar de aumentar la cantidad de clientes

El tamaño del grupo de sesiones de una aplicación determina cuántas transacciones simultáneas puede ejecutar una sola instancia de la aplicación. No se recomienda aumentar el tamaño del grupo de sesiones más allá de la simultaneidad máxima que puede controlar una sola instancia de la aplicación. Si la aplicación recibe una ráfaga de solicitudes que supera la cantidad de sesiones en el grupo, las solicitudes se ponen en cola mientras esperan que una sesión esté disponible.

Los recursos que consume la biblioteca cliente son los siguientes:

1. Cada canal de gRPC usa una conexión TCP.
2. Cada invocación de gRPC requiere un subproceso. La cantidad máxima de subprocesos que usa la biblioteca cliente es igual a la cantidad máxima de consultas simultáneas que ejecuta la aplicación. Estos subprocesos se agregan a los que la aplicación usa para su propia lógica empresarial.

No se recomienda aumentar el tamaño del grupo de sesiones más allá de la cantidad máxima de subprocesos que puede controlar una sola instancia de la aplicación. En su lugar, aumenta la cantidad de instancias de la aplicación.

Administra la fracción de sesiones de escritura

En algunas bibliotecas cliente, Spanner reserva una parte de las sesiones para las transacciones de lectura y escritura, lo que se denomina fracción de sesiones de escritura. Si tu app agota todas las sesiones de lectura, Spanner usa las sesiones de lectura y escritura, incluso para las transacciones de solo lectura. Las sesiones de lectura y escritura requieren una spanner.databases.beginOrRollbackReadWriteTransaction. Si el usuario tiene el rol de IAM spanner.databaseReader, la llamada falla y Spanner devuelve este mensaje de error:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Para las bibliotecas cliente que mantienen una fracción de las sesiones de escritura, puedes establecer la fracción de las sesiones de escritura.

Prácticas recomendadas para crear una biblioteca cliente o usar REST/RPC

A continuación, se describen las prácticas recomendadas para implementar sesiones en una biblioteca cliente de Spanner o para usar sesiones con las APIs de REST o RPC.

Estas prácticas recomendadas solo se aplican si desarrollas una biblioteca cliente o si usas las APIs de REST o RPC. Si usas una de las bibliotecas cliente de Google para Spanner, consulta Prácticas recomendadas para usar las bibliotecas cliente de Google.

Crea y dimensiona el grupo de sesiones

Para determinar un tamaño óptimo del grupo de sesiones para un proceso de cliente, establece el límite inferior en la cantidad de transacciones simultáneas esperadas y establece el límite superior en un número de prueba inicial, como 100. Si el límite superior no es adecuado, auméntalo. Aumentar la cantidad de sesiones activas usa recursos adicionales en el servicio de base de datos de Spanner, por lo que no limpiar las sesiones sin usar puede disminuir el rendimiento. Para los usuarios que trabajan con la API de RPC, recomendamos no tener más de 100 sesiones por canal de gRPC.

Administra sesiones borradas

Existen tres maneras de borrar una sesión:

• Un cliente puede borrar una sesión.
• El servicio de base de datos de Spanner puede borrar una sesión cuando esta permanece inactiva durante más de 1 hora.
• El servicio de base de datos de Spanner puede borrar una sesión si tiene más de 28 días de antigüedad.

Los intentos de usar una sesión borrada darán como resultado NOT_FOUND. Si encuentras este error, crea y usa una sesión nueva, agrégala al grupo y quita la sesión borrada del grupo.

Mantén en funcionamiento una sesión inactiva

El servicio de base de datos de Spanner se reserva el derecho de descartar una sesión sin usar. Si necesitas sí o sí mantener en funcionamiento una sesión inactiva, por ejemplo, si se espera un aumento significativo en el uso de la base de datos a corto plazo, entonces puedes evitar que se descarte la sesión. Realiza una operación económica, como ejecutar la consulta en SQL SELECT 1 para mantener activa la sesión. Si tienes una sesión inactiva que no se necesita para un uso a corto plazo, deja que Spanner descarte la sesión y, luego, crea una nueva la próxima vez que se necesite una sesión.

Un caso para mantener en funcionamiento las sesiones es controlar la demanda máxima normal en la base de datos. Si el uso intensivo de bases de datos ocurre todos los días de 9:00 a.m. a 6:00 p.m., debes mantener algunas sesiones inactivas en funcionamiento durante ese tiempo, ya que es probable que sean necesarias durante el uso máximo. Después de las 6:00 p.m., puedes permitir que Spanner descarte las sesiones inactivas. Antes de las 9:00 a.m. todos los días, crea algunas sesiones nuevas a fin de que estén listas para la demanda esperada.

Otra situación es si tienes una aplicación que usa Spanner, pero debe evitar la sobrecarga de conexión cuando lo hace. Puedes mantener un conjunto de sesiones en funcionamiento para evitar la sobrecarga de conexión.

Oculta detalles de sesión del usuario de la biblioteca cliente

Si creas una biblioteca cliente, no expongas las sesiones al consumidor de la biblioteca cliente. Proporciona al cliente la posibilidad de realizar llamadas a la base de datos sin la complejidad de crear y mantener sesiones. Para ver un ejemplo de una biblioteca cliente que oculta los detalles de la sesión al consumidor de la biblioteca cliente, consulta la biblioteca cliente de Spanner para Java.

Soluciona errores para escribir transacciones que no son idempotentes

Las transacciones de escritura sin protección de reproducción pueden aplicar mutaciones más de una vez. Si una mutación no es idempotente, una mutación que se aplica más de una vez podría provocar un error. Por ejemplo, una inserción puede fallar con ALREADY_EXISTS, incluso si la fila no existía antes del intento de escritura. Esto podría ocurrir si el servidor de backend confirmó la mutación, pero no pudo comunicar el resultado exitoso al cliente. En ese caso, se podría intentar otra vez la mutación, lo que provocaría el error ALREADY_EXISTS.

A continuación, se indican algunas formas posibles de solucionar esta situación cuando implementas tu propia biblioteca cliente o usas la API de REST:

• Estructura las escrituras para que sean idempotentes.
• Usa escrituras con protección de reproducción.
• Implementa un método que realice la lógica de "actualizar o insertar": inserta si es nuevo o actualiza si ya existe.
• Soluciona el error en nombre del cliente.

Mantén conexiones estables

A fin de obtener el mejor rendimiento, la conexión que usas para alojar una sesión debe permanecer estable. Cuando cambia la conexión que aloja una sesión, Spanner puede anular la transacción activa en la sesión y causar una pequeña cantidad de carga adicional en la base de datos mientras actualiza los metadatos de la sesión. No hay problema si algunas conexiones cambian de forma esporádica, pero debes evitar situaciones que podrían cambiar una gran cantidad de conexiones al mismo tiempo. Si usas un proxy entre el cliente y Spanner, debes mantener la estabilidad de la conexión para cada sesión.

Supervisa las sesiones activas

Puedes usar el comando ListSessions para supervisar las sesiones activas en tu base de datos desde la línea de comandos, con la API de REST o con la API de RPC. ListSessions muestra las sesiones activas de una base de datos determinada. Esto es útil si necesitas encontrar la causa de una fuga de sesión. (una fuga de sesión es un incidente en el que se crean sesiones, pero no se devuelven a un grupo de sesiones para su reutilización).

ListSessions te permite ver metadatos sobre tus sesiones activas, incluido cuándo se creó una sesión y cuándo se usó por última vez. Analizar estos datos te indicará la dirección correcta cuando soluciones problemas de las sesiones. Si la mayoría de las sesiones activas no tienen un approximate_last_use_time reciente, esto podría indicar que tu aplicación no está reutilizando las sesiones de forma correcta. Consulta la referencia de la API de RPC para obtener más información sobre el campo approximate_last_use_time.

Consulta la referencia de la API de REST, la referencia de la API de RPC o la referencia de la herramienta de línea de comandos de gcloud para obtener más información sobre el uso de ListSessions.

Limpieza automática de las filtraciones de sesiones

Cuando usas todas las sesiones de tu grupo de sesiones, cada transacción nueva espera hasta que se devuelva una sesión al grupo. Cuando se crean sesiones, pero no se devuelven al grupo de sesiones para su reutilización, se produce una fuga de sesiones. Cuando hay una fuga de sesión, las transacciones que esperan una sesión abierta se detienen de forma indefinida y bloquean la aplicación. Las fugas de sesiones suelen deberse a transacciones problemáticas que se ejecutan durante un tiempo extremadamente largo y no se confirman.

Puedes configurar tu grupo de sesiones para que resuelva automáticamente estas transacciones inactivas. Cuando habilitas la biblioteca cliente para que resuelva automáticamente la transición inactiva, identifica las transacciones problemáticas que podrían causar una fuga de sesión, las quita del grupo de sesiones y las reemplaza por una sesión nueva.

El registro también puede ayudar a identificar estas transacciones problemáticas. Si el registro está habilitado, los registros de advertencia se comparten de forma predeterminada cuando se usa más del 95% de tu grupo de sesiones. Si el uso de sesiones es superior al 95%, debes aumentar la cantidad máxima de sesiones permitidas en tu grupo de sesiones o es posible que tengas una fuga de sesiones. Los registros de advertencia contienen seguimientos de pila de las transacciones que se ejecutan durante más tiempo del esperado y pueden ayudar a identificar la causa del uso elevado del grupo de sesiones. Los registros de advertencia se envían según la configuración del exportador de registros.

Habilita la biblioteca cliente para resolver automáticamente las transacciones inactivas

Puedes habilitar la biblioteca cliente para que envíe registros de advertencia y resuelva automáticamente las transacciones inactivas, o bien para que solo reciba registros de advertencia.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Sesiones multiplexadas

Las sesiones multiplexadas te permiten crear una gran cantidad de solicitudes simultáneas en una sola sesión. Una sesión multiplexada es un identificador que usas en varios canales de gRPC. No genera cuellos de botella adicionales. Las sesiones multiplexadas tienen las siguientes ventajas:

• Menor consumo de recursos de backend debido a un protocolo de administración de sesiones más sencillo Por ejemplo, evitan las actividades de mantenimiento de la sesión asociadas con el mantenimiento de la propiedad de la sesión y la recolección de elementos no utilizados.
• Es una sesión de larga duración que no requiere solicitudes de mantenimiento de actividad cuando está inactiva.

Las sesiones multiplexadas se admiten en los siguientes casos:

• Las bibliotecas cliente de C++, Go, Java, Node.js, PHP, Python, Ruby y Rust

• Herramientas del ecosistema de Spanner que dependen de las bibliotecas cliente mencionadas, como PGAdapter, JDBC, Hibernate, el controlador de database/sql, el controlador de dbAPI y GORM.

• Herramientas del ecosistema de Spanner que dependen de las bibliotecas cliente de Java y Go, como PGAdapter, JDBC, Hibernate, el controlador de base de datos o SQL, y GORM. Puedes usar las métricas de OpenTelemetry para ver cómo se divide el tráfico entre el grupo de sesiones existente y la sesión multiplexada. OpenTelemetry tiene un filtro de métricas, is_multiplexed, que muestra sesiones multiplexadas cuando se establece en true.

Las sesiones multiplexadas son compatibles con todos los tipos de transacciones.

Las bibliotecas cliente rotan las sesiones multiplexadas cada 7 días para evitar el envío de transacciones en sesiones inactivas.

Las sesiones multiplexadas están habilitadas de forma predeterminada en algunas bibliotecas cliente. Para otras, debes usar variables de entorno para habilitarlas. Para obtener más detalles, consulta Habilita sesiones multiplexadas.

Consideraciones

Si intentas confirmar un cuerpo de transacción de lectura o escritura vacío, o una transacción en la que fallaron todas las consultas o declaración DML, hay un par de situaciones que debes tener en cuenta con las sesiones multiplexadas. Las sesiones multiplexadas requieren que incluyas un token de confirmación previa generado por el servidor en cada solicitud de confirmación. En el caso de las transacciones que contienen consultas o DML, debe haber al menos una transacción de consulta o DML correcta anterior para que el servidor envíe un token válido a la biblioteca cliente. Si no hubo consultas o transacciones de DML correctas, la biblioteca cliente agrega SELECT 1 de forma implícita antes de una confirmación.

En el caso de una transacción de lectura o escritura en una sesión multiplexada que solo tiene mutaciones, si una de las mutaciones es para una tabla o una columna que NO existe en el esquema, el cliente podría devolver un error INVALID_ARGUMENT en lugar de un error NOT_FOUND.

Habilita las sesiones multiplexadas

Las sesiones multiplexadas están habilitadas de forma predeterminada en las siguientes bibliotecas cliente:

• C++ en la versión 2.41.0 y posteriores.
• Go en la versión 1.85.0 y posteriores.
• Java en la versión 6.98.0 y posteriores.
• Node.js en la versión 8.3.0 y posteriores
• PHP en la versión 2.0.0 y posteriores.
• Python en la versión 3.57.0 y posteriores.
• Ruby en la versión 2.30.0 y posteriores.

Para usar sesiones multiplexadas en versiones anteriores de las bibliotecas cliente de Node.js, Java y Go, primero debes configurar una variable de entorno para habilitarla.

Para habilitar las sesiones multiplexadas, establece la variable de entorno GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS en TRUE. Esta marca también habilita la compatibilidad con sesiones multiplexadas para las transacciones de ReadOnly.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Para habilitar la compatibilidad con operaciones particionadas en sesiones multiplexadas, establece la variable de entorno GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS en TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS=TRUE

Para habilitar la compatibilidad con transacciones de lectura y escritura en sesiones multiplexadas, establece la variable de entorno GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW en TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW=True

Debes establecer GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS en TRUE como requisito previo para admitir una transacción en una sesión multiplexada.

Visualiza el tráfico de las sesiones normales y multiplexadas

OpenTelemetry incluye el filtro is_multiplexed para mostrar el tráfico de las sesiones multiplexadas. Establece este filtro en true para ver las sesiones multiplexadas o en false para ver las sesiones normales.

1. Configura OpenTelemetry para Spanner con los procedimientos de la sección Antes de comenzar de OpenTelemetry para Spanner.

2. Navega al Explorador de métricas.

   Ir al Explorador de métricas

3. En el menú desplegable Métrica, filtra por generic.

4. Haz clic en Tarea genérica y navega a Spanner > Spanner/num_acquired_sessions.

5. En el campo Filtro, selecciona una de las siguientes opciones:

   a. is_multiplexed = false para ver las sesiones regulares. b. is_multiplexed = true para ver las sesiones multiplexadas.

   En la siguiente imagen, se muestra la opción Filtrar con las sesiones multiplexadas seleccionadas.

Para obtener más información sobre el uso de OpenTelemetry con Spanner, consulta Aprovecha OpenTelemetry para democratizar la observabilidad de Spanner y Examina la latencia en un componente de Spanner con OpenTelemetry.

Solucionar problemas

Entre los errores comunes relacionados con las sesiones que puede encontrar tu aplicación, se incluyen los siguientes:

• Session not found
• RESOURCE_EXHAUSTED

Para obtener más información, consulta Errores de sesión.