Bueno, mi idea era evitar directamente tanto el get como el set; si se supone que las conexiones en el pool que busca getConnectionRO ya son readonly y READ_COMMITED, porque habría que hacer el “rechequeo y reseteo”.
La única forma que veo que estas conexiones pierdan estas características es que desde otro punto código haya algo como
Connection conn = DB.getConnectionRO();
conn.setReadOnly(false); O
conn.setTransactionIsolation(algo distinto a READ_COMMITED).
Pero no entiendo porque se habría de hacer esto (si se necesita una conexión con parámetros especiales, entonces ese código especifico la debería crear de manera excepcional y no andar tocando las que están en el pool de DB).
Haciendo una búsqueda de llamadas a Connection.setTransactionIsolation se ve que es llamada solamente en las clases DB_Orable, DB_Sybase (que no deben estar en uso supongo), DB_Posgres , CConnection, DB (getConnectionRO y getConnectionRW) [no termino de entender bien estas clases, pero parece que las conexiones son cacheadas en mas de un lugar]. A Connection.setReadOnly es solo llamado desde DB.getConnectionRO (y seguro que es ejecutado solo una vez por cada conexión creada). DB.getConnectionRO es llamada a su vez en pocos puntos.
Ahora me pongo a hacer un test: básicamente voy a comentar
la siguientes lineas en DB.getConnectionRO
if( !connection.isReadOnly()) {
connection.setReadOnly( true );
}
if( connection.getTransactionIsolation() != Connection.TRANSACTION_READ_COMMITTED ) {
connection.setTransactionIsolation( Connection.TRANSACTION_READ_COMMITTED );
}
y agregar un setReadOnly(true) al momento de crear el pool (porque eso si es necesario hacerlo al menos una vez). Si no me equivoco casi todas (por no decir todos) los accesos generados en al carga de ventanas usan la conexiones RO de DB.
Después voy a hacer un test de tiempo de carga de la ventana Endidades comerciales. Supongo que accediendo a un server en la misma maquina que usa el cliente (como es mi caso) tal vez no haya tanta diferencia (cuando hice el sniffeo, los paquetes generados por el “SHOW TRANSACTION…” tardan relativamente poco en la red; son paquetes chicos); ahora, en un red local, las cosas se deben hacer un poco más graves.
PD : no entendí bien el miedo al setter que comentas (jajaj pero si, en algún momento lo vi en el código como comentario), pero el setReadOnly y el setIsolationLevel si hay que tenerles un poco de “miedo”; disparan excepciones cuando hay una transacción en curso (http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/jdbc/pgjdbc/org/postgresql/jdbc2/AbstractJdbc2Connection.java?rev=1.54&content-type=text/x-cvsweb-markup ) pero no creo que te refieras a esto ya que las conexiones en el pool de DB son “autocommit” (y ahí nunca ha problemas… creo)
