Monthly Archives: January 2013

MySql connections autodrop after a certain hours


MySql is configured to drop any connection which has been Idle for more than 8 hours. What is the implication of this? After you return to your deployed app after a gap of 8 hours (If default SQL parameters have not been changed), you will be greeted with an exception.

How to solve this issue?

  1. Increase the wait_time parameter -Not a good Idea, it might unnecessarily hold on to the resources and not might be a sure shot way. Apart from that, being dependent on an “external” configuration for failover is not a very good idea -what if the server itself crashes, what if this configuration is missed in one of the instnaces, and many such issues will pop up against this approach.
  2. Use the parameter autoReconnect=true with JDBC URL -My SQl itself does not recommend this, have a look at link and people have reported that this does not work as well, refer link.
  3. Custom handling -have your code identify that connection has been lost and then recover it and try to reconnect, but then it would be a lot of fail over mechanism in code.
  4. The best way I found was to configure pooling mechanism as c3p0. See this post how to configure c3p0 in JPA for hibernate, it’s simple, easy and reliable.

So how do you test that issue is solved?

  1. Change wait_timeout in MySql to just 2 minutes, this is how it can be done from MySql workbench admin console mysql_timeout
  2. Keep value of idleTestPeriod less than wait_timeout -A quick recap what idleTestPeriod signifies
  3. idleTestPeriod:  default value=0; If this is a number greater than 0, c3p0 will test all idle, pooled but unchecked-out connections, every this number of seconds
    
  4. Login after wait_timeout has passed -it should not throw a exception
Advertisements

Solving classloading issue while adding pooling support using c3p0 in JPA with hibernate underneath


I added c3p0 for pooling in JPA, but encountered an exception

Unable to load class [org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider]

My configuration looked like

<property name="hibernate.connection.provider_class"
          value="org.hibernate.connection.C3P0ConnectionProvider" />
<property name="hibernate.c3p0.max_size" value="10" />
<property name="hibernate.c3p0.min_size" value="0" />
<property name="hibernate.c3p0.acquire_increment" value="5" />
<property name="hibernate.c3p0.idle_test_period" value="60" />
<property name="hibernate.c3p0.max_statements" value="0" />
<property name="hibernate.c3p0.timeout" value="100" />	    

Details about these properties and other defined at link

Looking at log trace it’s not difficult to figure out that jar is not correct, so first change, upgrade to latest c3p0 artifact.

Previous

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-c3p0</artifactId>
    <version>3.6.10.Final</version>
</dependency>

Latest

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-c3p0</artifactId>
    <version>4.1.9.Final</version>
</dependency>

After changing this, it worked but printed an Warning

WARN - HHH000208: org.hibernate.connection.C3P0ConnectionProvider has been deprecated in favor of org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider; that provider will be used instead.

This indicates that provider_class should be changed to remove the depricated class, so it should be

<property name="hibernate.connection.provider_class"
          value="org.hibernate.service.jdbc.connections.internal.C3P0ConnectionProvider" />

This cleanly integrated the c3p0 implementation.

Solving character encoding issue with Spring REST


While working on one of spring integration project, we fetched an XML using REST service and while we dumped it, we observed that many of characters were jumbled -which means encoding setting was screwed up. Spring integration configuration code

<int-http:outbound-gateway request-channel="testChannel"
		url="${test.url}" http-method="GET" expected-response-type="java.lang.String"
		reply-channel="glHeaderEnricher" charset="iso-8859-1">
		<int-http:uri-variable name="site_code"
			expression="payload" />
	</int-http:outbound-gateway>

As above mentioned, we were setting the expected char set as well.
“http:outbound-gateway” from Spring is nothing but a wrapper around Spring REST template, so started investigating what going on with REST template. REST template has option to inject message converters, by default converters which get registered are ByteArrayHttpMessageConverter, StringHttpMessageConverter, and ResourceHttpMessageConverter.

In spring integration configuration we had set “expected-response-type=”java.lang.String”” was causing StringHttpMessageConverter to be selected and used, and hence even before the XML payload reached our system it had lost it’s encoding.

Solution? using ByteArrayHttpMessageConverter, which can be done by setting

<int-http:outbound-gateway request-channel="testChannel"
		url="${test.url}" http-method="GET" expected-response-type="byte[]"
		reply-channel="glHeaderEnricher" charset="iso-8859-1">
		<int-http:uri-variable name="site_code"
			expression="payload" />
</int-http:outbound-gateway>

Once read as a raw byte it can be converted to string in any encoding.

How to log query parameters passed to JPA queries


I am using JPA with hibernate underneath. Using the property

<property name="hibernate.show_sql" value="true"/>

Shows just the SQL and not the values of parameters passed -it displays ? marks for query parameter as incomeexpe0_.transactiondate)>=?
Want to know what was the exact parameters passed -This is real helpful for debugging.
This can be achieved using hibernate logging -Add following two lines in your log4J.properties file

log4j.logger.org.hibernate.SQL=TRACE
log4j.logger.org.hibernate.type=TRACE

If this is used “log4j.logger.org.hibernate.SQL=TRACE” -No need to use property hibernate.show_sql, it wil take care of dumping queries.
The secondstatement, “log4j.logger.org.hibernate.type”, logs the JDBC parameters passed to a query

TRACE [main] (BasicBinder.java:83) - binding parameter [1] as [TIMESTAMP] - Thu Jan 03 01:00:18 IST 2013
TRACE [main] (BasicBinder.java:83) - binding parameter [2] as [TIMESTAMP] - Thu Jan 03 23:00:19 IST 2013

For even more advanced analysis and precise JDBC formatted queries (Non in an ORM form, but REAL sql), jdbc proxy driver like P6Spy can be used.

Advantages of a separate DAO layer


With the arrival of ORM most of operations related to DB, like managing connections, transaction management have been abstracted to a certain extent and this has led to many people believe that we can directly call the entitymanager from service layer. I agree that we hardly change persistence layer ( atleast in services, for products its very much can be a valid scenario), But then can we overlook following advantages of DAO layer (All related to DRY)?

  1. Exception handling at a centralized location for all DAO issues -most of time service layer just pass on the failure to client and do not take any action. DAO can logg the exception, for example hibernate exception, log the query -these all can help dig the issue, and throw a runtime exception which will keep service layer code cleaner
  2. What if same query is being called from multiple location -even inside same service, for example “get list of all students”. A change in in this query, lets say an additional criteria, will have to be tracked across all occurence . If there is DAO, it will be delegated there and changes wil be at single place
  3. A well designed DAO layer can be used across projects -for example recently I wrote a DAO for JCR queries, and most of its part as create node, create heirarchical node, delete node etc were exposed in a manner that the lib was used across project
  4. We might not change the DB, but may be ORM itself need to be changed -for example one of client code which needed a deployment on Google apps had to change from hibernate to JPA (Google apps support JPA but not hibernate) -having a separate DAO made life simpler
  5. On flip side, this does introduce more layers and extra level of delegation, but I feel it’s worth it.

Adding height and width to a Flex popup


A flex popup -typically of type title window, is by default 50% of the size of its parent and with hel of PopUPManager, it can be centered when loaded.
What if requirement is to have a fuller size popup window -size of it’s parent container?

  • One way is to use fixed height and width
  • other way is to resize it wrt it’s parent as
sectionPopUp.width=UIComponent(this.parentApplication).width;
sectionPopUp.height=UIComponent(this.parentApplication).height;

Not to say that first approach of using fixed height and width must be avoided as it will break on different screen sizes.
Approach two seemed more elegant to me .

Numeric null check on java server side failing with Flex BlazeDS AMF channel


One of the entities developed had a Numeric field as primary key, with a custom code to populate it rather than utilizing any auto generation strategy of JPA

if(ledegrHead.getLedgerHeadId()==null){
ledegrHead.setLedgerHeadId(financePersistence.getNextLedgerHeadId());
}

I wrote junit to test this and obviously it passed -if ID was set to null it would generate an ID.
But the moment I integrated it with flex, things went bad and it would NOT generate the expected “First” ID.
Reason – I had used autobinding on flex side –

[RemoteClass(alias="com.school.questionbank.Question")]
[Bindable]

This resulted in “auto” initialization of integer filed to zero and hence the condition of ==null would always fail. Solution? -explicit check for null as well as zero:

if(ledegrHead.getLedgerHeadId()==null||ledegrHead.getLedgerHeadId()<=0){
ledegrHead.setLedgerHeadId(financePersistence.getNextLedgerHeadId());
}

Comparing Integer in Java -autoboxing does not apply there


Hmm.. it came as most basic surprise for me, I wrote

this.questionId==question.getQuestionId()

where questionid is of type Integer (Object and not primitive).

Logically, it’s a reference comparison and should fail, but since its a wrapper for primitive type and a “special” scenario, my expectation was autoboxing will also apply here and will work properly, but no – it did not.
Correct way is either to use equals or just use intvalue

this.questionId.intValue()==question.getQuestionId().intValue()

Data truncation exception while joining one to one in JPA


Lets say a class is having one to one relation ship with other entity, it looks like

public class StudentDetails implements Serializable{
    @OneToOne(cascade={CascadeType.REFRESH,CascadeType.MERGE},fetch = FetchType.EAGER) 
    @Column(name="classid")
    private ClassDetails classId;
}

When I tried to save rows in the table, it threw an exception

javax.persistence.PersistenceException: org.hibernate.exception.DataException: Data truncation: Data too long for column 'classid' at row 1
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1377)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1300)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1306)
}

What went wrong? When I looked at generated table the filed type for classid was LOB while I expected it to be an int (It just an ID from foreign key). The culprit is -using column instead of joincolumn

public class StudentDetails implements Serializable{
    @OneToOne(cascade={CascadeType.REFRESH,CascadeType.MERGE},fetch = FetchType.EAGER) 
    @Column(name="classid")  
    private ClassDetails classId;

Instead of column, it should be join column

    @OneToOne(cascade={CascadeType.REFRESH,CascadeType.MERGE},fetch = FetchType.EAGER) 
    @JoinColumn(name="classid",nullable=false) <strong> See the joincolumn </strong> 
	private ClassDetails classId;}

If join column is not specified, JPA assumes that ClassDetails object will be saved (along with its all nested graph) to DB and hence it creates a LOB type -telling it that its a joined foreign key resulted in a int data type for the field.