Mantis - Resin
Viewing Issue Advanced Details
2579 minor always 04-08-08 09:55 04-09-08 10:13
emil  
ferg  
normal  
closed 3.1.6  
fixed  
none    
none 3.1.6  
0002579: NPE when using Amber with recommended MySQL driver
(Reported by Charles Lyon)

After a very frustrating day I still haven't got Amber to work as it should
on Resin 3.1.5. I have managed to get my examples to read things out of the
databases and update objects from data (and vice-versa) already in the
databases and this works beautifully. However, whenever I try to write a
new object into the databases, I get an NPE:

====== java.lang.NullPointerException at
com.caucho.sql.UserPreparedStatement.<init>(UserPreparedStatement.java:66)
at
com.caucho.sql.UserPreparedStatement.<init>(UserPreparedStatement.java:72)
at com.caucho.sql.UserConnection.prepareStatement(UserConnection.java:319)
at
com.caucho.amber.manager.AmberConnection.prepareInsertStatement(AmberConnection.java:2109)
at tests.TestObject.__caucho_create(TestObject.java) at
tests.TestObject.__caucho_flush(TestObject.java) at
com.caucho.amber.manager.AmberConnection.flushInternal(AmberConnection.java:2959)
at
com.caucho.amber.manager.AmberConnection.beforeCommit(AmberConnection.java:1788)
at
com.caucho.amber.manager.AmberConnection$EntityTransactionImpl.commit(AmberConnection.java:3457)
at example.TestServlet.service(TestServlet.java:64) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:91) at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:181)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:269)
at com.caucho.server.port.TcpConnection.run(TcpConnection.java:603) at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721) at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643) at
java.lang.Thread.run(Thread.java:619) ======

This is what I'm doing in a Servlet's service method:

======
  _entityManager.getTransaction().begin();
  TestObject to = new TestObject();
  to.setPrimaryHostname("test.myserver.com");
  to.setPrimaryIP("192.168.0.10");
  _entityManager.persist(to); // this is the problem line
  _entityManager.getTransaction().commit();
======

and if I comment out the penultimate line I have no problem, so it is just
the _entityManager.persist(to) invocation that causing the problem.

If I persist() any object already in the database that works without
exception (though granted it is not necessary to do this since it happens
automatically at commit).

My TestObject class is quite simple:

======
package tests;

import java.util.Collection;
import javax.persistence.*;

@Entity
@Table(name="servers")
public class TestObject {
    @Id
    private int id;

    private String primaryHostname;
    private String primaryIP;

    // and then just setters/getters for those properties
}
======




Okay, I have successfully traced the source of this problem. Firstly, I'm
using the current MySQL Connector/J 5.1.5 binary.

I was using the recommended MySQL driver (as per all the Resin tutorials)
which is:

com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource

However, if I change this to:

com.mysql.jdbc.Driver

then the problem I faced resolves itself. So one might think it's a problem
with that driver (which it might be - I haven't checked older versions of
Connector/J). As a temporary fix I'm leaving this as my driver - unless you
have a good reason not to?


However, I've gone further and delved into the source for the latest
snapshot (31st March). Using the MysqlConnectionPoolDataSource driver, I've
traced the problem to the following method:

com.caucho.sql.ManagedConnectionImpl.prepareStatement(UserConnection,String,int)

and the pair of lines:

if(resultType > 0)
  return conn.prepareStatement(sql,resultType);

This is returning null since the resultType passed in to the
prepareStatement method is 1. If I force resultType=0 in this method,
everything works as expected. I guess this is something to do with caching
statements (and for a new object being persisted those haven't already been
cached?), but I'll leave such inferences up to the experts ;)


Notes
(0002950)
ferg   
04-09-08 10:13   
jpa/0q1l