descargar - oracle jdbc driver java maven

OracleDataSource contra Oracle UCP PoolDataSource

Question

Estaba investigando algunos elementos JDBC Oracle Connection Pooling y encontré una nueva (más) implementación Oracle Pool llamada Universal Connection Pool (UCP). Ahora esto utiliza una nueva clase, PoolDataSource, para la agrupación de conexiones en lugar de OracleDataSource [con la opción de caché habilitada]. Estoy debatiendo si cambiar a esta nueva implementación, pero no puedo encontrar ninguna buena documentación sobre qué correcciones / actualizaciones (si las hay) me comprarían. Alguien tiene una experiencia con ambos? ¿Pluses / Minuses? Gracias.

Answer 1

El último controlador jdbc de Oracle (11.2.0.1.0) declara explícitamente que el caché de la conexión implícita de Oracle (que es aquel que usa OracleDataSource) está obsoleto:

Oracle JDBC Drivers versión 11.2.0.1.0 producción Readme.txt

¿Qué hay de nuevo en esta versión?

Conjunto de conexiones universales En esta versión, la característica Caché de conexiones implícitas de Oracle está en desuso. Se recomienda encarecidamente a los usuarios que usen el nuevo conjunto de conexiones universal. El UCP tiene todas las características del ICC, y mucho más. El UCP está disponible en un archivo jar separado, ucp.jar.

Entonces creo que es mejor comenzar a usar UCP, pero la documentación no es tan buena. Por ejemplo, no encontré la manera de usar UCP con la primavera ...

ACTUALIZACIÓN: He encontrado la configuración de resorte correcta: OK, creo que he encontrado la configuración correcta:

<bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
<property name="URL" value="jdbc:oracle:thin:@myserver:1521:mysid" />
<property name="user" value="myuser" />
<property name="password" value="mypassword" />
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleDataSource" />
<property name="connectionPoolName" value="ANAG_POOL" />
<property name="minPoolSize" value="5" />
<property name="maxPoolSize" value="10" />
<property name="initialPoolSize" value="5" />
<property name="inactiveConnectionTimeout" value="120" />
<property name="validateConnectionOnBorrow" value="true" />
<property name="maxStatements" value="10" />
</bean>

La clave es especificar la clase de fábrica correcta y el método de fábrica correcto

Answer 2

El almacenamiento en caché de conexiones implícitas funciona bastante mejor que UCP si usa la validación de conexión. Esto corresponde al error 16723836, que está programado para ser reparado en 12.1.0.2.

La agrupación de UCP se vuelve cada vez más costosa para obtener / devolver conexiones a medida que aumenta la carga concurrente. La prueba compara el almacenamiento en caché de la conexión implícita de Oracle, la agrupación de tomcat y UCP. Los 3 están configurados para permitir un máximo de 200 conexiones, un mínimo de 20 conexiones y un tamaño inicial de 2. Los 3 están configurados para validar las conexiones a medida que se eliminan del grupo. El grupo de tomcat usa la declaración "select sysdate from dual" para la validación.

Estos resultados en un nodo RedHat de 64 bits con 64 núcleos lógicos (32 físicos) y 128 GB de memoria RAM.

En 5 subprocesos concurrentes, UCP es el más lento, pero el tiempo total de administración de la conexión (obtener y cerrar) es inferior a 1 ms en promedio. A medida que aumenta la concurrencia, UCP se queda cada vez más atrás de las otras soluciones:

25 Threads:
Implicit: 0.58ms
Tomcat: 0.92ms
UCP: 1.50ms
50 Threads:
Implicit: 0.92ms
Tomcat: 1.60ms
UCP: 6.80ms
100 Threads:
Implicit: 2.60ms
Tomcat: 3.20ms
UCP: 21.40ms
180 Threads:
Implicit: 13.86ms
Tomcat: 15.34ms
UCP: 40.70ms

Answer 3

Hay dos formas posibles de usar UCP en Spring Bean.xml.

Para db.properties establecido por algún archivo, luego cárguelo y luego use uno de ellos:

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>classpath:resources/db.properties</value>
</property>
</bean>

El primero con oracle.ucp.jdbc.PoolDataSourceImpl: -

<bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceImpl">
<property name="URL" value="${jdbc.url}" />
<property name="user" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<property name="validateConnectionOnBorrow" value="true"/>
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleDataSource" />
<property name="connectionPoolName" value="TEST_POOL" />
<property name="minPoolSize" value="10" />
<property name="maxPoolSize" value="20" />
<property name="initialPoolSize" value="12" />
</bean>

El segundo con oracle.ucp.jdbc.PoolDataSourceFactory: -

 <bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory"
factory-method="getPoolDataSource">
<property name="URL" value="${jdbc.url}" />
<property name="user" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<property name="validateConnectionOnBorrow" value="true"/>
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleDataSource" />
<property name="connectionPoolName" value="TEST_POOL" />
<property name="minPoolSize" value="10" />
<property name="maxPoolSize" value="20" />
<property name="initialPoolSize" value="12" />
</bean>

Eso es todo :) Aquí está el enlace para la Documentación detallada: https://docs.oracle.com/cd/E11882_01/java.112/e12265/connect.htm#CHDDCICA

Answer 4

Hice una evaluación exhaustiva de UCP y decidí NO usar UCP. Mire esta publicación para obtener más información.

Answer 5

PDS es ''universal'' ya que proporciona el mismo nivel de funcionalidad de agrupamiento que obtienes en ODS para bases de datos que no son de Oracle, por ejemplo, MySQL.

Consulte la Guía de desarrollo de UCP , un artículo en el sitio web de Oracle y la Guía de transición de UCP.

No veo ningún beneficio inmediato de pasar a UCP (PDS) desde ODS, pero quizás en el futuro Oracle desaproveche parte de la funcionalidad en ODS. Usé ODS por un tiempo y estoy bastante contento con él por el momento, pero si comenzara de nuevo, iría con PDS.

Answer 6

Probé el UCP y lo implementé en producción en una aplicación Spring 3.0.5 Hibernate utilizando contenedores de escucha Spring JMS y sesiones y transacciones gestionadas por Spring utilizando la anotación @Transactional. Los datos a veces causan errores de restricción SQL, debido a hilos de escucha independientes que intentan actualizar el mismo registro. Cuando eso ocurre, la excepción es lanzada por un método anotado por @Transactional y el error se registra en la base de datos utilizando otro método anotado por @Transactional. Por alguna razón, este proceso parece dar como resultado una fuga del cursor, que finalmente se suma y desencadena el error del límite abierto del cursor ORA-01000, lo que hace que el hilo deje de procesar cualquier cosa.

OracleDataSource que se ejecuta en el mismo código no parece perder cursores, por lo que no causa este problema.

Este es un escenario bastante extraño, pero me indica que es demasiado pronto para usar el UCP en una aplicación con este tipo de estructura.

Answer 7

Probé ucp y el rendimiento es mejor ... Puede ser que la clave es usar esto

oracle.ucp.jdbc.PoolDataSource ds = (oracle.ucp.jdbc.PoolDataSource)envContext.lookup(url_r);
MyConnectionLabelingCallback callback = new MyConnectionLabelingCallback();
ds.registerConnectionLabelingCallback( callback );
Properties label = new Properties();
label.setProperty(pname, KEY);
conn = ds.getConnection(label);

Esto ayuda a tomar prestada la conexión y nunca cerrarla ... por lo que el rendimiento es excelente

El código para la clase de devolución de llamada es

public class MyConnectionLabelingCallback
implements ConnectionLabelingCallback {
public MyConnectionLabelingCallback()
{
}
public int cost(Properties reqLabels, Properties currentLabels)
{
// Case 1: exact match
if (reqLabels.equals(currentLabels))
{
System.out.println("## Exact match found!! ##");
return 0;
}
// Case 2: some labels match with no unmatched labels
String iso1 = (String) reqLabels.get("TRANSACTION_ISOLATION");
String iso2 = (String) currentLabels.get("TRANSACTION_ISOLATION");
boolean match =
(iso1 != null && iso2 != null && iso1.equalsIgnoreCase(iso2));
Set rKeys = reqLabels.keySet();
Set cKeys = currentLabels.keySet();
if (match && rKeys.containsAll(cKeys))
{
System.out.println("## Partial match found!! ##");
return 10;
}
// No label matches to application''s preference.
// Do not choose this connection.
System.out.println("## No match found!! ##");
return Integer.MAX_VALUE;
}
public boolean configure(Properties reqLabels, Object conn)
{
System.out.println("Configure################");
try
{
String isoStr = (String) reqLabels.get("TRANSACTION_ISOLATION");
((Connection)conn).setTransactionIsolation(Integer.valueOf(isoStr));
LabelableConnection lconn = (LabelableConnection) conn;
// Find the unmatched labels on this connection
Properties unmatchedLabels =
lconn.getUnmatchedConnectionLabels(reqLabels);
// Apply each label <key,value> in unmatchedLabels to conn
for (Map.Entry<Object, Object> label : unmatchedLabels.entrySet())
{
String key = (String) label.getKey();
String value = (String) label.getValue();
lconn.applyConnectionLabel(key, value);
}
}
catch (Exception exc)
{
return false;
}
return true;
}
}

Answer 8

Yo también estoy probando UCP y estoy descubriendo que tengo problemas de rendimiento en una aplicación basada en Thread Pool. Inicialmente, probé OracleDataSource, pero tengo problemas para configurarlo para el procesamiento por lotes. Sigo recibiendo NullPointerExceptions en las conexiones, lo que me lleva a pensar que tengo algún tipo de pérdida de conexión, pero solo con alguna aplicación, hay otras aplicaciones que administramos que no están orientadas a procesos por lotes que OracleDataSource funciona bien.

Basado en este post y en algunos otros que encontré investigando sobre este tema, probé UCP. Descubrí que con ajustes suficientes, podía deshacerme de las conexiones cerradas / NullPointerExceptions en los errores de estilo de las conexiones, pero Garbage Collection estaba recibiendo una paliza. El GC a largo plazo se llena rápidamente y no parece liberarse hasta que la aplicación termine de ejecutarse. Esto a veces puede tomar tanto como un día o más si la carga es realmente pesada. También noto que también lleva más tiempo procesar los datos. Lo comparo con la ahora depreciada clase OracleCacheImpl (que actualmente usamos en producción porque todavía "simplemente funciona"), donde utilizó un tercio de la memoria GC que UCP hace y procesa los archivos mucho más rápido. En todas las demás aplicaciones, UCP parece funcionar bien y maneja casi todo lo que le ofrezco, pero la aplicación Thread Pool es una aplicación importante y no podía poner en riesgo las Excepciones GC en producción.