Annyce Davis

Davis Technology Consulting

Updated: Mocking Hibernate Create Criteria in Grails’ Unit Test with GMock

by

Using the GMock Library I have updated my unit tests to mock out the create criteria methods the following way: 

void testSomeFunction() {
    def results = []

    def mockCriteria = mock() {
      list(instanceOf(Closure)).returns(results)
    }

    mock(Book).static.createCriteria().returns(mockCriteria)

    play {
      assertEquals null, bookService.getDefaultBook(null)
    }
  }

You need to add the following to the top of the unit test file with the import statements:

import org.gmock.*
import static org.hamcrest.Matchers.*

@WithGMock

Also add the following to your BuildConfig.groovy:

dependencies {
    test "org.gmock:gmock:0.8.0"
    test "org.hamcrest:hamcrest-all:1.0"
}

I learned this from the following blog post: http://adhockery.blogspot.com/2010/01/using-gmock-to-complement-grails.html

Why you should upgrade to Grails 1.3.5

by

I did a profile of my Grails application with JVisualVM running Grails 1.3.4 and then again running Grails 1.3.5.  What a difference!  The memory leak issue that was referred to here http://jira.codehaus.org/browse/GRAILS-6622 was fixed in the 1.3.5 release.  I believe that a similar memory leak was affecting my application as well.  Across the board, the application is faster and has a much smaller memory footprint.  I have attached a snapshot of the memory comparison for the two versions to this post.

Memory Comparison of Grails 1.3.4 and Grails 1.3.5

3 Tips to Help Avoid the Hibernate Flush

by

When using Grails, the default behavior of Hibernate is to do a flush before queries, at the end of requests, and pretty much whenever Hibernate feels like it. So here are three tips that can help you avoid some of the flushing and/or at the very least decrease the number of database connections that Hibernate attempts to get:

  1. Use read() function when possible: If you are only going to read some field of a domain object and will make no changes to it, then just use object.read(), instead of the get() method
  2. Make sure your services are only transactional if they need to be, so if you are not updating, saving, or deleting records in the db chances are you do not need your Service to be transactional
  3. If you do have some transactional logic, put it inside a domain.withTransaction {} closure instead of making the entire function or class transactional

Configuration of DataSource.groovy for Highly Concurrent Grails Application

by

In developing a highly concurrent Grails Application, I ran into an issue where many connections were being created to the database and were subsequently not released. After reading several blog posts it seems that the library used to handle the connection pooling was not designed for highly concurrent systems. I found that using the following setup in your DataSource.groovy file eliminates the stale connection issue and allows a high level of concurrency.

dataSource {
pooled = true
driverClassName = “com.mysql.jdbc.Driver”
dialect = “org.hibernate.dialect.MySQL5InnoDBDialect”
properties {
maxActive = 50
maxIdle = 10
initialSize = 10
minEvictableIdleTimeMillis = 10000
timeBetweenEvictionRunsMillis = 20000
maxWait = 10000
validationQuery = “/* ping */”
testWhileIdle = true
numTestsPerEvictionRun = 3
testOnBorrow = true
}
}

Hope this can help someone else.

Follow Me