org.hibernate.exception.GenericJDBCException: Cannot release connection
    at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
    ..
    ..
Caused by: java.sql.SQLException: Already closed.

Not only that the messages polluted my inbox, the exception was visible to the enduser, resulting in a HTTP 500 error. An older blog post i found suggested dismissing DBCP and using c3p0, a solution that i’m not quite found of. At least, the post helped to reproduce the problem within my development setup. The underlying problem was indeed the MySQL wait_timeout.

There’s quite a long documentation on the Tomcat JDBC Connection Pool. Although the Tomcat team recommends their own solution since Tomcat 7, i still wanted to go with DBCP.

The relevant keywords are “testOnBorrow”, “testOnReturn”, “testWhileIdle”, “validationQuery” and “timeBetweenEvictionRunsMillis”. The first 3 are boolean values. If set to true, the query given as validationQuery is executed on borrowing a connection from the pool, on returning or when idling. The first option is not an option on production use as the query is executed before each call. Although “Select 1″ is probably very fast, i just don’t want to have. Also: The problem is an invalidated, idle connection so i set testWhileIdle to true. And what happened? Nothing! The problem stayed. So there is the last option timeBetweenEvictionRunsMillis which should, according to the docs, default to 5 seconds but it doesn’t. The documentation is wrong. It’s under zero, so the eviction thread that tests idle connections never run. I’ve tweeted the tomcat team, but there was no reaction.

So the correct configuration for a DBCP pool database source is:

<Resource
	type="javax.sql.DataSource"
	driverClassName="com.mysql.jdbc.Driver"
	maxActive="100"
	maxIdle="30"
	maxWait="10000"
	testOnBorrow="false"
	testOnReturn="false"
	testWhileIdle="true"
	validationQuery="Select 1"
	timeBetweenEvictionRunsMillis="1800000"
/>

This way the eviction thread runs every 30 minutes, testing idle connections with the query “Select 1″ and removing them from the pool. The timeBetweenEvictionRunsMillis should not be to low. It should be adapted to the configured MySQL wait_timeout.

Share This

To my surprise, many other developers actually read this tweets and helped me out on some problems. Thanks a lot gals and guys, i really appreciate that. Me rambling isn’t meant to be personal at any time, i guess you know how easily one gets frustrated with too less time and too much stuff to do.

Anyway, here are some shortcuts that could eventually be helpful. I’m gonna add more to this list the next days:

Enabling hibernate filters in the grails session

Took me a little digging through the source code, but i came up with the following idea:

import org.springframework.transaction.support.TransactionSynchronizationManager;
 
class SecurityFilters {
  def sessionFactory
  def filters = {
    login(controller:'*', action:'*') {
      before = {
        // get your user id somewhere
        def whatsoeveruserId = 0
        def sessionHolder =  TransactionSynchronizationManager.getResource(sessionFactory);     
        sessionHolder.getSession().enableFilter("filterByOwner").setParameter("currentUserId", whatsoeveruserId);
      }
    }
  }
}

I want to have some kind of rowlevel security through a Hibernate filter. Through dependency injection i get hold of the sessionFactory and through the TA Manager, i get the current session on which i can enable my filter.

Doing this in a Grails filter, i can combine this with some kinda login mechanism and i’m good to go.

Whitelisting attributes through bindData

To me it’s a bad idea using blacklisting on data binding as i can and will forget attributes that must not be updated through a webform.

With Marc i found the following solution:

bindData(entity, params, entity.properties.collect{it.key} - ['foo', 'bar'])

That way only attributes foo and bar gets updated.

Anyway, with Grails 1.1 this won’t be necessary anymore as Graeme anonced.

Graeme was so kind to comment on this: This feature is already in 1.0.x, i just didn’t find it, have a look at the docu at The Web Layer.

bindData(entity, params,  [include:['foo', 'bar']])

Updates on 2008/12/9

Adding custom errors to a domain class

The grails reference has a handy example for adding custom errors to domain classes, have a look here. This works quite well except that all other errors from databinding are mysteriously gone.

For me, the following steps worked to update a user (change some persistent attributes and the transient attributes password and passwordConfirmation):

bindData(anwender, params, [include:['name', 'vorname', 'password', 'passwordConfirmation']])
 
if(params.password != "" && params.password == params.passwordConfirmation)
  anwender.hashPassword() // As alway, never ever store plaintext passwords ;)
else if(params.password != "") {
  anwender.validate() // IMPORTANT without that step, possible other errors from bindData vanished
  anwender.errors.rejectValue('password', 'user.anwender.passwords_doesnotmatch')
}

Afterwords, hasErrors() show all errors, i.a. non nullable fields and the like.

More thoughts

I somewhat used to hibernate and come along very well with it, even though i’m actually a SQL fan. I guess if my inside into the Spring Framework would be a little bit deeper, some areas wouldn’t be hard to understand.

On the other hand i think that Grails does a great job for J2EE based development and it should do so even more. As always, there is the law of leaky abstractions, but the whole butload of stuff that is the J2EE stack should be abstracted away.

Updates on 2009/2/6

Grails 1.1-beta3

I use hibernate validator in my domain classes (that i created outside of rails as hibernate annotated classes) and i got

java.lang.NoSuchMethodError: org.hibernate.event.PreInsertEvent.getSource()Lorg/hibernate/engine/SessionImplementor

on every insert and update. Hibernate validator 3.0.0.GA is incompatible with the Hibernate version in Grails 1.1-beta3. Problem was gone after upgrading validator to 3.1.0.GA.

Some other stuff:

• Installed plugins are obviously gone. i.e yui plugin is still in the application folder, it needs to be reinstalled after upgrade (grails install-plugin yui)

  Ok, i see this was done on purpose: “Plugins are now stored in your USER_HOME directory. You will need to re-install your plugins or run” (from the beta2 release note). Not a good decision making this a default imho. I like having my apps pinned to specific plugins.

• The message method for doing I18n in controllers used to be available in filters. This method seems to be gone. No solution for that so far.
• Values not bound in a form are not null anymore but 0 in case of numeric values. Bummer! Actually my bad.
• Some problems solved.

Share This

The type of the discriminator can be one of

string, character, integer, byte, short, boolean, yes_no, true_false

In case you need to use any other than string or character, i.e. integer, you have to give the base class a default discriminator-value like 0 or -1 or whatever fits, otherwise you’ll end up with a an exception like:

org.hibernate.MappingException: Could not format discriminator value to SQL string

as Hibernate uses the class name of the base class to derive a default value.

Share This

Mapping Spatial Oracle type SDO_GEOMETRY to JGeometry

The only quirk with this solution as of February 2007 is the fact, it won’t work with null columns. The fault lies in nullSafeSet. Either can the JGeometry delegate be null or, what is worse, preparedStatement.setNull( i, Types.OTHER); will fail with an invalid column type. The correct version of this method is as follows:

public void nullSafeSet( PreparedStatement preparedStatement, Object o, int i) throws HibernateException, SQLException {
  if( o == null) {
    preparedStatement.setNull(i, Types.STRUCT, "MDSYS.SDO_GEOMETRY");
  } else {
    if( o instanceof JGeometryType) {
      JGeometryType gt = (JGeometryType) o;
      OracleConnection oc = (OracleConnection) preparedStatement.getConnection().getMetaData().getConnection();
      if(gt.getJGeometry() == null)
        preparedStatement.setNull(i, Types.STRUCT, "MDSYS.SDO_GEOMETRY");
      else
        preparedStatement.setObject( i, JGeometry.store( (JGeometry) (gt).getJGeometry(), oc));   
    }
  }
}

Furthermore, i think the spatial dialect should be registered with the following class:

public class OracleSpatialDialect extends Oracle9Dialect {
	public OracleSpatialDialect() {
    super();
      registerColumnType( Types.OTHER, "MDSYS.SDO_GEOMETRY");
  }
}

Kudos to Joel Schuster from Navisys for the adapter class!

Share This