electrocucaracha

Continuando con la serie de operaciones con numeros grandes, desarrollo la implementacion de una suma de valores contenidos en una cadena, la cual nos puede evitar el desboramiento de bufer. Realizando un ligero analisis encontramos que seguimos limitados por el manejo de indices de arreglos, ya que solo nos permite indexarlos con numeros enteros.

Suma.java

...
	private static String sumar(String a, String b) {
		//Validaciones
...
		int x, y, result = 0;
		int limite = a.length() > b.length() ? a.length() : b.length();
		char[] tmp = new char[limite + 1];
		for (int i = 1; i <= limite; i++){
			x = i <= a.length() ? a.charAt(a.length() - i) - '0' : 0;
			y = i <= b.length() ? b.charAt(b.length() - i) - '0' : 0;
			result += x + y;
			tmp[tmp.length - i] = (char) ((result % 10) + '0');
			result /= 10;
		}

		if ( result > 0){
			tmp[0] = (char) ((result % 10) + '0');
			return String.valueOf(tmp);
		}
		return String.valueOf(tmp, 1, tmp.length -1);
	}

Esta implementacion surgio de la necesidad de implementar una solucion para la multiplicacion de numeros grandes, me refiero a numeros que su resultado causaran el desboramiento de bufer. Mi propuesta se baso en la utilizacion de cadenas para su representacion y manejo de datos, pienso que la solucion que encontre es relativamente buena y quizas tenga muchos puntos a mejorar, lo cual se aceptan sugerencias.

Quiza una de las mayores limitantes que tengo es que el tipo de valor para el indice de los arreglos solo puede ser entero, esto reduce la cantidad de digitos con los cuales puedo trabajar.

Multiplicacion.java

...
	private static String multiplicar(String a, String b) {
		//Validaciones
...		
		StringBuffer result = new StringBuffer();
		int x = a.length();
		int y = b.length();
		int i;
		int j;
		long[][] results = new long[x][y];
		List sum = new LinkedList();
		long tmp;

		for (i = 0; i < x; i++) {
			for (j = 0; j < y; j++) {
				results[i][j] = (a.charAt(i) - '0') * (b.charAt(j) - '0');
			}
		}

		x--;
		y--;
		tmp = 0;

		while (true) {
			j = y;
			i = x;
			while (j >= 0 && i < a.length()) {
				tmp += results[i][j];
				i++;
				j--;
			}
			sum.add(tmp % 10);
			tmp /= 10;

			if (x > 0) {
				x--;
			} else if (y > 0) {
				y--;
			} else {
				if(tmp > 0){
					sum.add(tmp);
				}
				break;
			}
		}
		Collections.reverse(sum);
		for (long l : sum) {
			result.append(l);
		}

		return result.toString();
	}

Una propiedad de Hibernate la cual es muy útil y que nos permite visualizar las consultas realizadas sobre la base de datos, es show_sql la cual al activarse nos muestra las consultas HQL realizadas sobre la base de datos.

hibernate.properties

hibernate.show_sql = true

Aunque es una propiedad muy util, muchas veces es necesario conocer los valores que son enviados o recibidos por la base de datos; en muchos de estos servidores es posible configurarlos para generar trazas de las consultas realizadas, el problema de hacerlo de esta forma, es que para una base de datos muy concurrida, aun siendo de desarrollo, resulta complicado encontrar la consulta realizada.

Para obtener los valores enviados podemos utilizar dos frameworks, Log4j y P6Spy.

Cuando utilizamos el framework de Log4j solo se requiere la modificación de su configuración añadiendo una propiedad.

log4j.properties

log4j.logger.org.hibernate.type=trace

Lo cual nos muestra, de forma separada, el tipo y valor de cada parámetro enviado en la consulta.

Output

13:20:43,281 TRACE StringType:153 - binding 'root' to parameter: 1
13:20:43,296 TRACE BooleanType:153 - binding 'true' to parameter: 2

Otra forma y quizás mas elegante de mostrar las consultas que se realizan es utilizando P6Spy, para lo cual es necesario configurarla, con los siguientes pasos:

• Descargar la ultima version de p6spy-install.zip de su sitio oficial.
• Descomprimir y copiar en el proyecto los archivos p6spy.jar y spy.properties.
• Realizar las configuraciones necesarias para incluir los jars en el proyecto.
• Modificar la configuración de la base de datos. Remplazando el driver utilizado por com.p6spy.engine.spy.P6SpyDriver.

hibernate.properties

#hibernate.connection.driver_class = com.mysql.jdbc.Driver
hibernate.connection.driver_class = com.p6spy.engine.spy.P6SpyDriver

• Por ultimo, es necesario modificar el archivo spy.properties, agregando el driver class que fue remplazado y, en caso de que estemos utilizando Log4j, utilizar su appender. Y quizás sea necesario que elimine del registro los drivers.

spy.properties

# mysql Connector/J driver
 realdriver=com.mysql.jdbc.Driver

#specifies the appender to use for logging
appender=com.p6spy.engine.logging.appender.Log4jLogger

#the DriverManager class sequentially tries every driver that is
#registered to find the right driver.  In some instances, it's possible to
#load up the realdriver before the p6spy driver, in which case your connections
#will not get wrapped as the realdriver will "steal" the connection before
#p6spy sees it.  Set the following property to "true" to cause p6spy to
#explicitily deregister the realdrivers
deregisterdrivers=true

Dando como resultado en la siguiente salida:

Output

p6spy - 1275601495062|0|2|statement|select this_.iId as iId7_5_, ... , adeudos6_.mMonto as mMonto2_4_ from tblUsuario this_ left outer join tblTarjeta tarjetas2_ on this_.iId=tarjetas2_.iIdUsuario left outer join tblAbono abonos3_ on tarjetas2_.iId=abonos3_.iIdTarjeta left outer join tblAclaracion aclaracion4_ on tarjetas2_.iId=aclaracion4_.iIdTarjeta left outer join tblEntradasSalidas entradassa5_ on tarjetas2_.iId=entradassa5_.iIdTarjeta left outer join tblAdeudo adeudos6_ on tarjetas2_.iId=adeudos6_.iIdTarjeta where this_.vchUser=? and this_.bActivo=? order by this_.iId asc limit ?|select this_.iId as iId7_5_, ... , adeudos6_.mMonto as mMonto2_4_ from tblUsuario this_ left outer join tblTarjeta tarjetas2_ on this_.iId=tarjetas2_.iIdUsuario left outer join tblAbono abonos3_ on tarjetas2_.iId=abonos3_.iIdTarjeta left outer join tblAclaracion aclaracion4_ on tarjetas2_.iId=aclaracion4_.iIdTarjeta left outer join tblEntradasSalidas entradassa5_ on tarjetas2_.iId=entradassa5_.iIdTarjeta left outer join tblAdeudo adeudos6_ on tarjetas2_.iId=adeudos6_.iIdTarjeta where this_.vchUser='root' and this_.bActivo='true' order by this_.iId asc limit 1

Lo cual muestra la consulta original sin sustituir los valores, y la consulta creada por el framework sustituida por los valores utilizados.

Mas que nada quise postear sobre este patrón de diseño, ya que en un reciente proyecto donde el requerimiento era utilizar RMI, al usarlo me pareció estupendo, ya que en lugar de crear varias interfaces y estarlas registrando, solo fue necesario crear una sobre la cual se centraba y administraba la ejecución de acciones. En este patrón existen varias clases que juegan un papel importante: Invoker, o el cliente que realiza la petición de ejecutar la acción; CommandManager, quien administra y controla la ejecución de acciones; AbstractCommand, como clase común para todas las acciones concretas y por ultimo ConcreteCommand, que es la implemetancion de cada acción.

A continuación muestro el diagrama de clases utilizado

Sesion.java

public class Sesion {
...
public Parametro ejecutar(Parametro p) throws AvException {
			try {
				p.setUsername(usuario.getUser());
				Parametro out = RemoteStubCache.getStubToRemoteObject(host).ejecutar(
							p);

				return out;
			} catch (RemoteException e) {
				throw new AvException(
						"Ha occurrido un error al intentar ejecutar "
								+ "la accion :" + p.getAccion(), e);
			}
		}// ejecutar
}//Sesion

Como CommandManager e implementando una interfaz para exponer métodos con RMI:

ServerRemoteImpl.java

public class ServerRemoteImpl implements ServerRemote, Unreferenced {
...
	public Parametro ejecutar(Parametro param) throws RemoteException {
		log.info("Inicio - ejecutar(Parametro param)");

		BaseAccion accion = BaseAccion.getAccion(param.getAccion());
		Parametro p = null;
		if (accion != null) {
			log.debug("Ejecutar : " + param.getAccion());
			try {
				p = accion.ejecutar(param);
			} catch (AvException e) {
				log
						.error("Ha ocurrido un error al intentar ejecutar la accion");
				throw new RemoteException("Ha ocurrido un error al intentar "
						+ "ejecutar la accion", e);
			}
		} else {
			log.warn("Accion no encontrada");
		}

		log.info("Fin - ejecutar(Parametro param)");

		return p;
	}// ejecutar
}// ServerRemoteImpl

En cuanto a AbstractCommand, cabe notar que agregue métodos para obtener las acciones y beans, estos métodos se basan en clases de Spring:

BaseAccion.java

public abstract class BaseAccion {
...

	public static Object getBean(String bean) {
		return getContext().getBean(bean);
	}// getBean

	public static BaseAccion getAccion(String accion) {
		if (accion != null && accion.trim().length() > 0) {
			return (BaseAccion) getContext().getBean(accion);
		}
		return null;
	}// getAccion

	public abstract Parametro ejecutar(Parametro parametro) throws AvException;
}// BaseAccion

Y por ultimo un ejemplo de alguna acción concreta o ConcreteCommand, que en este caso corresponde a la acción de agregar un usuario

AgregarAccion.java

public class AgregarAccion extends BaseAccion {

	private static Logger log = Logger.getLogger(AgregarAccion.class);

	@Override
	public Parametro ejecutar(Parametro parametro) throws AvException {
		log.info("Inicio - ejecutar(Parametro parametro)");

		UsuarioLayer ul = (UsuarioLayer) getBean(UsuarioLayer.BEAN_NAME);
		Usuario u = null;
		if (parametro.getValor(Tipo.INPUT) instanceof Usuario) {
			u = (Usuario) parametro.getValor(Tipo.INPUT);
			ul.agregar(u);
			parametro.setValor(Tipo.OUTPUT, u);
		}

		log.info("Fin - ejecutar(Parametro parametro)");

		return parametro;
	}// ejecutar
}// AgregarAccion