All Downloads are FREE. Search and download functionalities are using the official Maven repository.

org.eclipse.persistence.config.ExclusiveConnectionMode Maven / Gradle / Ivy

There is a newer version: 5.0.0-B03
Show newest version
/*
 * Copyright (c) 1998, 2020 Oracle and/or its affiliates. All rights reserved.
 *
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License v. 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0,
 * or the Eclipse Distribution License v. 1.0 which is available at
 * http://www.eclipse.org/org/documents/edl-v10.php.
 *
 * SPDX-License-Identifier: EPL-2.0 OR BSD-3-Clause
 */

// Contributors:
//     06/08/2008-1.0M9 Andrei Ilitchev
//        - New file introduced for bug 235433: Can't customize ConnectionPolicy through JPA.
package org.eclipse.persistence.config;

/**
 *
 * This property could be specified while creating either EntityManagerFactory
 * (createEntityManagerFactory or persistence.xml)
 * or EntityManager (createEntityManager); the latter overrides the former.
 *
 * The "isolated case" mentioned below is the case of some (or all) entities requiring isolated cache.
 * That could be achieved either by specifying the property for one or more entities:
 *   eclipselink.cache.shared.Employee {@literal ->} "false"
 * or for all entities:
 *   eclipselink.cache.shared.default {@literal ->} "false"
 * Note that this property(es) could be specified only on persistence unit level (cannot be passed to createEntityManager method).
 *
 * 

JPA persistence property Usage: * *

properties.add(PersistenceUnitProperties.EXCLUSIVE_CONNECTION_MODE, ExclusiveConnectionMode.Isolated); * *

Values are case-insensitive. * "" could be used instead of default value ExclusiveConnectionMode.DEFAULT. * * @see PersistenceUnitProperties */ public class ExclusiveConnectionMode { /** * The value causes creation of * IsolatedClientSession in isolated case * and ClientSession otherwise. * Connection is kept exclusive for the duration of Eclipselink transaction. * Inside Eclipselink transaction all writes and reads performed through the exclusive connection. * Outside Eclipselink transaction a new connection is acquired from connection pool * for each read and released back immediately after the query is executed. * * Note that Eclipselink transaction usually starts later then JTA transaction does, * or entityManager.beginTransaction method is called: Eclipselink usually waits until * it's about to perform a query that potentially alters data base's state to start * Exclipselink transaction. That reflects in connection usage in Transactional mode. * Example: * // Eclipselink transaction is not started yet - readQuery1 acquires and immediately releases connection. * readQuery1.getResultList(); * entityManager.getTransaction().begin(); * // Eclipselink transaction still not started yet - readQuery2 acquires and immediately releases connection. * readQuery2.getResultList(); * entityManager.persist(new Employee()); * // Eclipselink transaction is not started yet - readQuery3 acquires and immediately releases connection. * readQuery3.getResultList(); * entityManager.flush(); * // Before the flushing is performed Exclipselink transaction is started: * // connection is acquired that will be kept until the end of transaction and used for all reads and writes. * readQuery4.getResultList(); * entityManager.commit(); * // Eclipselink transaction is completed, the connection used by Eclipselink transaction is released; * // readQuery5 acquires and immediately releases connection. * readQuery5.getResultList(); * * There's a way to force beginning of Eclipselink transaction right before executing the first query after em.getTransaction().begin(): * "eclipselink.transaction.join-existing" {@literal ->} true. * In the example that setting would force Exclipselink transaction top begin right before readQuery2 is executed * and therefore cause execution of readQuery2 and readQuery3 through the exclusive connection * (of course the same connection would be used by readQuery4 and flush, too). * However this approach could hardly be recommended: * none of the objects read after Eclipselink transaction begins * get into the shared cache unless altered therefore seriously reducing benefits of Eclipselink shared cache. */ public static final String Transactional = "Transactional"; /** * The value causes creation of * ExclusiveIsolatedClientSession in isolated case * and throws exception otherwise. * Connection is kept exclusive for the whole lifetime of the owning EntityManager. * Inside Eclipselink transaction all writes and reads performed through the exclusive connection. * Outside Eclipelink transaction only isolated entities are read through the exclusive connection; * for non isolated entities a new connection is acquired from connection pool * for each read and released back immediately after the query is executed. * * In the example presented above all five readQueries * would read isolated entity through the exclusive connection, * however non-isolated entity would be read the same as in Transactional mode. */ public static final String Isolated = "Isolated"; /** * The value causes creation of ExclusiveIsolatedClientSession * in both isolated and non-isolated cases. * Connection is kept exclusive for the whole lifetime of the owning EntityManager. * All writes and reads performed through the exclusive connection. * * In the example presented above all five readQueries * would read all entity through the exclusive connection. * * Note that though all entities use the exclusive connection * only isolated entities use isolated cache; non-isolated entities use shared cache. */ public static final String Always = "Always"; public static final String DEFAULT = Transactional; }





© 2015 - 2024 Weber Informatics LLC | Privacy Policy