Ggravity Opensource

After a year in the Apple Store, I decided to release the source code of Ggravity.

You can download it from Ggravitysoft

Enjoy it!

Tools for the Objective Assessment of Psicophysicological States

My final degree project: Tools for the Objective Assessment of Psicophysicological States.

I defended this project in 2004 at ETS of Telecommunication Engineering (Málaga University), graduating with Honours.

It is a C/C++ framework to implement real time processing systems focused to study mental states through the analysis of ECG (Electro Cardiography), Photopletismography and GSR (Galvanic Skin Response)

This is the book in spanish (sorry, but I wish I had time to translate 450 pages)

This is the presentation (PowerPoint)

This is a zip with the sources, binaries, documents, test signals, etc.

Some videos:

• ECG signal and two processors, one to detect the pulses and the other one to calculate the AR spectrum of the HRV (Heart Rate Variability) - Video
• Photopletismography signal and two processors, one to detect the pulses and the other one to calculate the AR spectrum of the HRV (Heart Rate Variability) - Video
• Use of the Wizard to create real time processors - Video

Nemo of Persia

This is a J2ME mobile game I developed during a master degree in 2005.

You can download de source code of this great game from: NemoPersia

I developed it using the J2ME Wireless Toolkit v2.2 so download it and play!

Asociaciones en Grails (GORM)

A continuación voy a hacer un pequeño resumen de las asociaciones más típicas que podemos hacer en GRAILS mediante GORM.

1.- Asociaciones Unidireccionales

1.1.- Muchos a uno (m:1) sin relación de pertenencia

class Face {

Nose nose

}

class Nose {

}

En este caso la foreign key va en la tabla padre referenciando a la tabla hija.

insert into nose (id, version) values (null, ?)

insert into face (id, version, nose_id) values (null, ?, ?)

Aunque parezca que la relación es uno a uno (1:1), realmente es muchos a uno ya que una instancia Face sólo puede referenciar a una instancia Nose sin embargo una instancia Nose puede estar referenciada por muchas instancias Face distintas ya que no se está indicando ninguna restricción en este sentido.

Como la tabla hija no pertenece a la padre, es decir no se ha especificado belogsTo, los saves y deletes no se propagarán desde la tabla padre a la hija.

Es decir,

def face = new Face(nose:new Nose())

face.save()

generará una excepción porque al no propagarse los saves la instancia Nose no se persitirá no pudiéndose persistir por tanto la instancia de Face al referenciar a un Nose que no existe a nivel de base de datos (transient).

En este caso es necesario hacer

def nose = new Nose()

nose.save()

def face = new Face(nose:nose)

face.save()

Al invocar a nose.save(), estamos diciendo que la instancia, que en ese momento es de tipo transient, pase a ser persistent y gestionada por la sesión. Esto no quiere decir que en ese momento se grabe realmente en base de datos.

Hibernate grabará en base de datos los objetos de la sesión en base a unas reglas, por ejemplo siempre que termine de generarse una vista. Si necesitamos que en un preciso momento, un save se refleje en base de datos deberemos hacer obj.save(flush:true)

Por la misma razón, el borrado de una instancia Face no borrará su Nose asociada.

Sin embargo sí que se podrá actualizar una instancia Nose desde una Face que la referencie. Por ejemplo:

def face = Face.get(1)

face.nose.cualquierPropiedad=valor

face.save()

En este caso, aún no especificandose belongsTo en la clase Nose, los cambios hechos se persistirán en base de datos. El motivo es que al invocar a

face.nose.cualquierPropiedad=valor

se lee la instancia Nose de base de datos (queda en estado persistent) y se actualiza en memoria por lo que cuando se persiste la sesión, se guardan los cambios de Nose en base de datos.

1.2.- Muchos a uno (m:1) con relación de pertenencia

class Face {

Nose nose

}

class Nose {

static belongsTo = Face

}

En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.

insert into nose (id, version) values (null, ?)

insert into face (id, version, nose_id) values (null, ?, ?)

Mediante la clausula belongsTo estamos especificando que una instancia de Nose pertenece a una instancia de Face. Las implicaciones son que los saves y deletes son propagados desde el padre al hijo. Es decir, podemos crear una instancia Face con una Nose transient:

def face = new Face(nose:new Nose())

face.save()

De igual forma, un delete sobre una instancia de Face borrará también la instancia Nose a la que referencia.

1.3.- Uno a uno (1:1) sin relación de pertenencia

Para modelar una relación muchos a uno (m:1) simplemente deberemos tomar una relación muchos a uno (m:1) y hacer que la referencia de la parte muchos sea única:

class Face {

Nose nose

static constraints = { nose unique: true }

}

class Nose {

}

En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.

insert into nose (id, version) values (null, ?)

insert into face (id, version, nose_id) values (null, ?, ?)

Ahora una instancia Face sólo puede referenciar a una instancia Nose y una instancia Nose sólo puede estar en una Face al declararse unique.

Esta forma tan rara y poco intuitiva de modelar relaciones 1:1 viene heredada de Hibernate.

Al no especificarse relación de pertenencia con belongsTo los saves y deletes no son propagados desde la instancia padre a la hija.

1.4.- Uno a uno (1:1) con relación de pertenencia

class Face {

Nose nose

static constraints = { nose unique: true }

}

class Nose {

static belongsTo = Face

}

En este caso también la foreign key va en la tabla padre referenciando a la tabla hija.

insert into nose (id, version) values (null, ?)

insert into face (id, version, nose_id) values (null, ?, ?)

En este caso al especificarse relación de pertenencia con belongsTo los saves y deletes son propagados desde la instancia padre a la hija.

1.5.- Uno a muchos (1:m) sin relación de pertenencia

class Author {

static hasMany = [ books : Book ]

}

class Book {

String title

}

En este caso, a nivel de base de datos esta relación se modela mediante una tabla auxiliar (join)

Siempre, en las relaciones uno a muchos (1:m) por defecto se propagan los saves desde la clase padre a la hija aunque no se haya especificado relación de pertenencia con belongsTo. En este caso, como no se ha especificado una relación de pertenencia (belongsTo) si borramos la clase padre no se borrará la hija referenciada.

En las relaciones uno a muchos, lo más normal es añadir instancias en la clase padre mediante el método dinámico addTo.

Por ejemplo:

aAuthor.addToBooks(title:"Mi Libro")

aAuthor.save()

Debemos tener cuidado en este caso ya que a nivel de base de datos, no se persistiría inmediatamente la lista de los libros de un autor aunque invoquemos a save. En este caso si leemos de base de datos justo despues de hacer el save no obtendremos ningún registro:

println Book.list()*.title

El motivo es que Hibernate decide que en ese momento no es necesario persistir a base de datos posponiendolo para más adelante. Para hacer que en ese momento los datos queden registrados en base de datos es necesario invocar a save con flush:true

Sin embargo, en las relaciones 1:1 y m:1 que hemos visto una vez que hacemos:

def author = new Author(new Book())

author.save

las instancias Book y Author son creadas en base de datos por lo que una query a base de datos devolverían estos nuevos registros.

La razón es que en la relación 1:m, una instancia de la clase padre (Author) puede referenciar a cero o N libros (Book) mientras que en la relación 1:1 o m:1 una instancia de la clase padre tiene que referenciar necesariamente a un libro ya que la foreign key está en la tabla padre. Por lo tanto, en el primer caso Hibernate puede posponer la inserción en base de datos para más tarde mientras que en el segundo caso la inserción debe realizarse en el momento.

2.- Asociaciones Bidireccionales

2.1.- Uno a uno (1:1) con FK desde padre a hijo

class Face {

Nose nose

}

class Nose {

static belongsTo = [face:Face]

}

En este caso la foreign key va en la tabla padre referenciando a la tabla hija.

insert into nose (id, version) values (null, ?)

insert into face (id, version, nose_id) values (null, ?, ?)

Resaltar que la clausula belongsTo es distinta a la de las asociaciones unidireccionales, en este caso en la clase Nose se indica una propiedad face de tipo Face (face:Face) que es la referencia hacia atrás entre Nose y Face.

Al especificarse una relación de pertenencia, los saves y deletes son propagados desde el padre al hijo.

2.2.- Uno a uno (1:1) con FK desde hijo a padre

class Face {

Nose nose

static hasOne = [nose:Nose]

}

class Nose {

Face face

}

Este caso es idéntico al anterior salvo que la foreign key va en la tabla hija referenciando a la tabla padre.

insert into face (id, version) values (null, ?)

insert into nose (id, version, face_id) values (null, ?, ?)

Resaltar que no tiene sentido definir hasOne en la clase padre y belongsTo en la clase hija ya que estaríamos indicando cómo almacenar la FK de forma contradictoria.

2.3.- Uno a muchos (1:m)

class Author {

static hasMany = [ books : Book ]

}

class Book {

static belongsTo = [author:Author]

}

Este caso es idéntico a la relación unidireccional 1:m salvo que la hemos hecho bidireccional creando una asociación entre Book y Author mediante una clausula de pertencia belongsTo a través de la propiedad author de la clase Book.

Ahora, al haberse especificado una relación de pertenencia, si borramos la clase padre se borrará también la clase hija referenciada.

A nivel de base de datos esta relación se modela mediante una tabla auxiliar (join)

Imaginemos que tenemos una asociación bidireccional entre dos entidades y que en la clase hija existen dos propiedades del tipo de la clase padre:

// Esto no funciona

class Airport {

static hasMany = [flights:Flight]

}

class Flight {

Airport departureAirport

Airport destinationAirport

}

Este ejemplo no funcionaría porque no se sabe cuál de las dos propiedades de Flight: departureAirport o destinationAirport correspondería a la referencia inversa entre Airport y Flight. Es decir, desde un Airport conocemos todos los vuelos mediante la relación hasMany llamada flights, sin embargo desde un vuelo (instancia Flight) no sabríamos a qué aeropuerto pertenece ya que existen dos propiedades que apuntan a Airport.

Para solventar esto es necesario mapear en la clase padre la propiedad de la hija que va a corresponderse con la referencia inversa.

class Airport {

static hasMany = [flights:Flight]

static mappedBy = [flights:"departureAirport"]

}

class Flight {

Airport departureAirport

Airport destinationAirport

}

Ahora una instancia de Airport tienen muchos vuelos (flights), y desde un vuelo podemos conocer desde qué aeropuero salió mediante la propiedad departureAirport.

2.4.- Muchos a muchos (m:m)

class Book {

static belongsTo = Author

static hasMany = [authors:Author]

}

class Author {

static hasMany = [books:Book]

}

Las relaciones muchos a muchos (m:m) se modelan a nivel de base de datos mediante una tabla join.

Esta tabla join no puede ser modelada para añadir propiedades de la relación entre la clase padre y la hija que podamos necesitar.

Por esta razón, a veces cuando pensamos en relaciones muchos a muchos, es más conveniente pensar en dos relaciones uno a muchos apuntando la parte de los muchos a una nueva entidad donde podremos almacenar información extra aunque este consejo quizás no aplique a nuestra relación entre Author y Book ya que es demasiado simple.

Sondasplorer - A bytecode instrumentalization framework (current state)

Here it is a small presentation about the current state of Sondasplorer, the framework to inspect J2EE apps that I am developing in my very sparse free time.

Sondasplorer Presentation in english
Presentación de Sondasplorer en español

ORA-01000 and Sentences Cache

One issue I have come across recently is the leak of cursors in a application in a high concurrency more than 600 users and more than 30 pages served per second. With this conditions, after 10 minutes of test, I started to see the ORA-01000 Maximum Number of Cursors Exceeded exception frequently.

If I executed the above second query, I saw that some users of my application had really reached the 300 real opened cursors that are the maximum number of cursors per session configured in Oracle. We can see this parameter with the following query:

  SELECT name, value FROM v$parameter WHERE name='open_cursors'

After analyzing the application source code deeply, I confirmed that it was releasing the database resources properly, CallableStatements in this case, so the problem seemed to be another. After a little debugging I realized that when the PreparedStatement was closed the
cursor keeped opened which could mean two things: a bug in the server application or the Oracle driver or that the application server was using any kind of setences cache ... it was a good thing that the problem was the second supposition.

The application was being executed in WebSphere which has a statement cache to optimize the processing of prepared statements and callable statements implementing the PreparedStatement interface with a propietary IBM class. When the number of cached statements is less than the size of this cache, a close over the statement doesn't really close the
resources, it is like a "soft" close. The execution of the query to show the opened cursors shows the real opened cursors, these "soft" closed cursors too!!

The problem was that the size of this cache was configured with a value of 1000 so when the Oracle limit of 300 was reached, started to fail with ORA-01000 exceptions because no statement was close because the total count was always <1000(<300 because of the Oracle limit)

PreparedStatements and Oracle Cursors

One thing we must always bear in mind when an application goes to a production environment is that it uses the shared resources properly. In this case, I'll talk about Oracle cursors related to PreparedStatements. Every time we execute a PreparedStatement a cursor is opened and it is not released until an explicit close is not invoked. The right way is to release the PreparedStatement, the ResultSet if exists and the Connection, for example:

// Create a connection or get one from a pool
Connection con = getConnection();
...
PreparedStatement ps = null;
ResultSet rs = null;

try {
 ps = con.prepareStatement(sqlIsi);
 rs = ps.executeQuery();
}finally {
 if (rs!=null)
   try {rs.close();} catch(SQLException e) {}
 if (ps!=null)
   try {ps.close();} catch(SQLException e) {}
}

...

// Release the connection:
//   close the connection or return it to the pool
con.close();

We always have to release the resources in a finally block so the release is always executed even if exceptions are thrown in the try block. Doing that we'll avoid cursors leaks and the ugly ORA-01000 Maximum Number of Cursors Exceeded.

Concerning to the execution speed, every time a query is invoked, Oracle have to parse it. In the case of PreparedStatements, sentences with a high probability of being executed multiple times, the parsing time can be high. This time can be reduced by caching the sentences once parsed and that's what Oracle does. Oracle maintains a cache table where it stores the parsed sentences, speeding up the execution when the same ones are frequently invoked. As this cache is not unbounded, we have to invoke the PreparedStatements in a proper way: they have to be parametrized. For example:

  select name,number from person where id=2451
  select name,number from person where id=?

From a functional point of view, the above sentences are identical, they retieve the information of a person from his/her Id. But from a performance point of view they are very different. If that kind of sentences have to be executed a lot of times, the overall execution of sentences will perform better with the second sentence because the cache will be working well.

In the first case, if the Id is different, every time this sentence is invoked, it has to be parsed because it really is a new sentence:

  select name,number from person where id=2451
  select name,number from person where id=1121
  select name,number from person where id=5489
  select name,number from person where id=...

In the second case, the sentence is always the same:

  select name, number for person where id=?

We can monitorize the cached sentences using the following query:

  SELECT a.sid, user_name, status,
  osuser, machine, c.sql_text
  FROM v$session b, v$open_cursor a, v$sql c
  WHERE a.sid = b.sid
  AND a.address=c.address
  AND a.user_name IN (
    SELECT DISTINCT user_name FROM v$session)
  AND user_name={user_name}
  ORDER BY user_name DESC, a.sid, c.sql_text, 3;

where {user_name} has to be replaced by the desired user. Even though in the above sentence we are querying from the open_cursor table, this table doesn't contain real opened cursors but cached statements!!!

In order to know the real opened cursors of a session, we have to use a sentence like the following:

  SELECT a.value, s.username,
    s.sid, s.serial#, p.spid
  FROM v$sesstat a, v$statname b,
    v$session s, gv$session s2
  JOIN gv$process p ON p.addr = s2.paddr
  AND p.inst_id = s2.inst_id
  WHERE a.statistic#=b.statistic#
  AND s.sid=a.sid AND s.sid=s2.sid
  AND s.username={user_name}
  AND b.name = 'opened cursors current';

It is important to remark that the CallableStatement interface extends from PreparedStatement so all said about PreparedStatements also applies to classes implementing this interface. This means that sentences like:

  BEGIN mypackage.myprocedure(param1,param2);END;

must be replaced by:

  BEGIN mypackage.myprocedure(?,?);END;

in order to improve the performance using the statements cache properly.