Like I posted here we are currently busy replacing the Postgres database with an Oracle database. One issue we encountered was the use of boolean fields in the Postgres database, because there is no such type in the Oracle database. So we chose to create a Varchar2(1) field that contains a ‘t’ or ‘f’, being ‘true’ or ‘false’.
But since our application has already been written for the biggest part, we are already making use of boolean fields in our Java code. But that’s where Hibernate comes to the rescue. We are using Hibernate3 as our ORM framework. With Hibernate it is very easy to convert a boolean in the Java code to a char value in the database by extending the class ‘CharBooleanType’ to create your own custom type. I have the java code we used for our type here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package net.pascalalma.hibernate.types;
 
import org.hibernate.type.CharBooleanType;
 
public class TrueFalseType extends CharBooleanType {
 
	protected final String getTrueString() {
		return "t";
	}
 
	protected final String getFalseString() {
		return "f";
	}
}

To use this type in our Entity classes I have defined the type with a package annotation (yes, we are using Hibernate annotations at our project). This package scoped annotation is a nice feature since JDK5 which I hadn’t used or seen before. I have created a file ‘package-info.java’ like this:

1
2
3
4
5
6
7
8

@TypeDefs(
  {@TypeDef(name="truefalse-type",typeClass = TrueFalseType.class)}
)
package net.pascalalma.hibernate.entity;
 
import net.pascalalma.hibernate.types.TrueFalseType;
import org.hibernate.annotations.TypeDef;
import org.hibernate.annotations.TypeDefs;

(By the way, I read somewhere that the javadoc generator will take the javadoc in this package-info.java as package javadoc, even if there is also a package.html defined in this package)
Now in the entity classes in the package ‘net.pascalalma.hibernate.entity’ I can use the defined Type like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

package net.pascalalma.hibernate.entity;
 
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.Table;
 
import org.hibernate.annotations.Type;
 
@Entity
@Table(name="MYTABLE")
 
public class MyTable {
 
	Long id;
	Boolean indicator;
	String name;
 
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	@Id
	@Column(name="ID")
	public Long getId() {
		return id;
	}
	public void setId(Long id) {
		this.id = id;
	}
 
	@Column(name="indicator")
	@Type(type="truefalse-type")
	public Boolean getIndicator() {
		return indicator;
	}
 
	public void setIndicator(Boolean indicator) {
		this.indicator = indicator;
	}
}

And that’s it. More changes aren’t necessary to solve this issue, so we can continue our conversion untill we run into the next issue :-)

Do you recognize this: Although you are using a tool to develop your applications for some time, you are suddenly surprised by a certain error message you haven’t seen before? And you didn’t do anything different compared to the last time you used it.
Well, my experience is that in 100 times out of a 100, you did do something different. My last time in this situation was when I wanted to use a Java 1.5 enum type as a field in my EJB3 entity bean. I had done this before and at first sight everything looked well. Here was what I did:
Since I deploy my EJB3 application on JBoss 4.2.1 I supplied JBoss with the following Hibernate configuration file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
 
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
	version="1.0">
	<persistence-unit name="kpn-jf" transaction-type="JTA">
		<jta-data-source>java:/jdbc/my-datasource</jta-data-source>
		<properties>
			<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
			<property name="hibernate.max_fetch_depth" value="3" />
			<property name="hibernate.hbm2ddl.auto" value="create" />
			<property name="hibernate.show_sql" value="true" />
		</properties>
	</persistence-unit>
</persistence>

With this file the EJB container creates all database objects when I deploy my application (although this goes against everything I have learned as former ‘database’ developer I now just enjoy the simplicity of it).
The enum type I was using was defined as:

1
2
3
4
5
6
7

package net.pascalalma.domains;
 
public enum Gender {
		U, // Unknown
		M, // Male
		F  // Female
}

And the Entity Bean I was using:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Entity
@Table(name = "CUSTOMERS")
@NamedQueries(value = { @NamedQuery(name = "findCustomerByCode", query = "SELECT o FROM Customers o WHERE code = :code") })
public class Customer
{
	private long id;
	private String code;
	private String initials;
	private String lastName;
	private Gender gender;
 
        ......
 
        @Column(name = "GENDER")
	public Gender getGender() {
		return gender;
	}
	......

Now, like I said before, at first there seemed nothing wrong with my application. I could run it and when I persisted Customers to the database I noticed rows were created in the database, so far so good. However, it went wrong as soon as I started to select an existing row and tried to make an Entity object of it. It was at this point I got the following stacktrace:

Caused by: java.lang.IllegalArgumentException: Unknown name value for enum class net.pascalalma.domains.Gender: 2
at org.hibernate.type.EnumType.nullSafeGet(EnumType.java:104)
at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:105)
at org.hibernate.type.AbstractType.hydrate(AbstractType.java:81)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2096)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308)
at org.hibernate.loader.Loader.getRow(Loader.java:1206)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.doList(Loader.java:2220)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
at org.hibernate.loader.Loader.list(Loader.java:2099)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:378)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:80)
at net.pascalalma.entities.Customer.findCustomerByCode(Customer.java:124)
at net.pascalalma.services.CustomerServiceBean.validateCustomer(CustomerServiceBean.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerIntercep
tor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
… 55 more
Caused by: java.lang.IllegalArgumentException: No enum const class net.pascalalma.domains.Gender.2
at java.lang.Enum.valueOf(Enum.java:192)
at org.hibernate.type.EnumType.nullSafeGet(EnumType.java:101)
… 88 more

Of course, my first reaction was WTF!?!?! This worked before and why doesn’t it work right now??
Well, as an experienced developer I knew there had to be something different with the last time I did this (the chance it was the computer thinking, hey, let’s do something else today seemed not so big ;-) ).
So after a short investigation I found out that I had forgotten an annotation in my Entity bean when defining the Gender field as enum. After adding this:

@Enumerated(EnumType.STRING)

the value of the enum was stored as String, and could be used succesfully when constructing the Entity object.
So this gives ‘my mistake’ vs. ‘computer mistake’ 101 to 0…..

To store information in our PostgreSQL database we use Spring and Hibernate as I mentioned earlier in my posts. Some of our tables in the database also have GIS information with them. That’s why we are also using PostGIS extension on our database. This GIS information (Geometry) is also reflected in the Hibernate objects we use to persist our data.
We have experienced that this Geometry data can be invalid, in which case the database (JDBC) is throwing an UncategorizedSQLException. This is the case, for example, when a Polygon has a different start and ending point.
In our application we have two kinds of exceptions: the CustomException (thrown and handled by ourselves) and all other exceptions not handled by us. With this distinction between the exceptions I can decide what to do when an exception occurs, for example, when storing data in the database: is it our CustomException, then it is most probably a problem with this instance and I will move to process the next instance. If there is thrown another Exception, then there is something seriously wrong and I will stop the processing.
This may sound good in theory but it appeared that when an instance with invalid geometry was stored in the database, the whole process was stopped because there occured an UncategorizedSQLException. The code we used to store our Hibernate object is this:

1
2
3
4
5
6
7
8
9
10

 public void insert(final CustomObject e) throws CustomException {
      try {
         dao.insert(e);
      } catch (UncategorizedSQLException ex) {
         // We assume the geometry was invalid
         throw new CustomSystemException(CustomErrorMessage.CSM_SYS019, ex);
      } catch (DataAccessException ex) {
         throw new SystemException(ex);
      }
   }

While this code was working fine in our unit tests it kept failing in our application. After some research we discoverd the (logical, like always) reason for this: since we are using Hibernate to persist our data it is Hibernate that determines when the data is posted to the database. And tests showed that this is done when a commit is fired. And that is the big difference between our real-world application and our unit test. In our application we perform a lot of other steps before we fire the commit. So the code has already passed the try-catch before the database is throwing the UncategorizedSQLException. In our unit test we just called this insert and performed a commit right-away, so the exception is thrown inside the try-catch.
So that was the problem but now we had to think about the solution. We came up with 3 options:

1. Use AOP to act on every thrown UncategorizedSQLException with a ThrowsAdvice and make it a CustomException.
2. To call flush() after each insert() and update() so the data is posted in the database right away.
3. Perform the validation of the geometry ourselves before we send it to the database.

So first we try the flush() because this one was the easiest to implement. While this gave the behaviour we wanted we didn’t like the fact that we decided when to flush the data instead of letting Hibernate decide this. This could be giving performance issues at some time so we decided to investigate the other solution too.
The second attempt was the AOP option. Because I haven’t used this before (besides the default out-of-the-box Spring functionlity) I was curious how to get it to work. Well, I got the ThrowsAdvice working for every exception that was thrown in our code, but not for the UncategorizedSQLException. I guess that that is caused by the fact that this exception is thrown by AOP itself, and therefor can not be ‘catched’ by another AOP, but I am not sure about this yet.
Finally, because of time-pressure I decided to go for the last option. We were doing all kinds of validations already on the Geometry so I added the one for the polygons. This is performance wise the best solution and I am also very sure what the implications are for the rest of the application.
But someday when I have more time, I am definitely having another look at this AOP thing, because that part is worth some more investigation.

When you are working with Hibernate there is a big chance you have (or will) run into the lazy loading exception: org.hibernate.LazyInitializationException: failed to lazily initialize a collection – no session or session was closed. Well, last week it was my turn. Luckiliy there are lots and lots of articles and blogs about it on the net so in a short time you will have enough information about it to fill at least a day or two by reading them.
In our case we had in one of our objects a OneToMany relation with a child object and it’s fetchType was set to EAGER. Now this doesn’t have to be a bad choice but in our case it wasn’t always necessary to collect the children when the parent was created. So I just set the fetchType to LAZY and tested it… And there it was: the LazyinitializationException.
So apparently we were trying to load the Object children while there was no (Hibernate) session anymore to which the parent object was attached. After a short search it appeared that the cause of this problem lay in the Transaction demarcation we had defined in Spring (we are using the combination Spring-Hiberate in our project).
We have a ‘classic’ layer structure in our components going from business layer -> service layer -> dao layer. Now we had transactions defined at both business layer and service layer. This caused that some objects were created in one transaction, that transaction ended also ending the Hibernate session, and then the object was used, so it tried to lazy load its children but without a Hibernate session…. et voila: the lazy loading exception. So we did a redesign of our transaction demarcation and this time we only started and ended transactions in our business layer: the correct place according to us. This made the transactional behaviour much more clear but also lead to another problem.
A lot of our unit-test cases are testing at the service layer level. Some of them were failing now since there was no transaction defined at this level. So we decided to make each test method runnning in its own transaction. But we didn’t want to have to declare all our test classes in the Spring context. So we made a base test class that sets the transactions programmatically. To have this working with TestNG 5.0 we made the following base class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

import net.pascalalma.util.MyContext;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.orm.hibernate3.HibernateTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionDefinition;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
 
/**
 * Use this class as base class for your test if you need transactional context
 * in your tests. If this is not needed you should use CoreTest as base class.
 * A transactional is started before the test-method is ran and the transaction will
 * be rolled back when the test method has finished. If you need the data to be committed
 * to the database you can call 'setComplete()'. This will perform a commit on the
 * current transaction.
 *
 * @author Pascal Alma
 *
 */
public class TransactionalCoreTest {
 
   private static final Log LOG = LogFactory.getLog(TransactionalCoreTest.class);
 
   private HibernateTransactionManager mgr = null;
   private TransactionStatus status = null;
 
   /**
    * Starts a transaction.
    */
   @BeforeMethod
   protected void setUp() {
      // Obtaining the Spring context
      ClassPathXmlApplicationContext ctx = MyContext.getContext();
      // Set the transactionManager
      mgr = (HibernateTransactionManager) ctx.getBean("transactionManager");
      // Start the transaction
      status = mgr.getTransaction(new DefaultTransactionDefinition());
 
      LOG.debug("Transaction started");
   }
 
   /**
    * Commits the changes in the current transaction. At default changes are lost as the
    * transaction is rolled back at the end of the testcase.
    *
    */
   protected void setComplete() {
      if (!status.isCompleted()) {
         mgr.commit(status);
      }
   }
 
   /**
    * Ends the current transaction by rolling back the changes (if any).
    *
    */
   @AfterMethod
   protected void tearDown() {
      if (!status.isCompleted()) {
         mgr.rollback(status);
      }
      LOG.debug("Transaction ended");
   }
}

So, if we have a test class that needs transactional behaviour we extend from this base class. If we are testing at business layer level, we extend a test base class without this transactional behaviour. This is working fine for us for now, but if you think your solution is better, please let me know! I am always willing to learn new things, especially if these thing are better then the ones I know :-)