Saint Johns Development Team

While learning to use JDO with datanucleus for a project to be run in app engine I tried to implement a method that gets a collection of persistant objects from the database. Trying to test the results I used the size() method on the collection. The result was following exception:

org.datanucleus.exceptions.NucleusUserException: Object Manager has been closed
at org.datanucleus.ObjectManagerImpl.assertIsOpen(ObjectManagerImpl.java:3816)
at org.datanucleus.ObjectManagerImpl.findObjectUsingAID(ObjectManagerImpl.java:2073)
....

The solution is simple. To iterate throw the objects of the collection, they have to be in a detached state, not in persistant state.

So the code in the dao class would look like:

public Collection getAllValueObjects() {
Collection results = Collections.checkedCollection(getJdoTemplate().find(ValueObject.class), ValueObject.class);
 
// To iterate the collection it has to be detached
getPersistenceManager().detachCopyAll(results);
 
return results;
}

I experience sporadically the following problem in Joomla 1.5:

There was a GWT application that used c3p0 as a connection pool manager. This application had two connections for two different databases, one for the authentication and the other for the data retrieval.

Starting the application the user had to fill the login form and wait for the authorization. This action didn't use the c3p0. Then in the next step the application showed up 3 dropdown, each populated with its own query. Those 3 queries got the connection throw a datastore which used the c3p0 to serve connections.

So, after the authendication, many exceptions showed up in the console, many failures from the c3p0, like this:
WARN [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2] com.mchange.v2.resourcepool.BasicResourcePool (1841) - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@425eb9 -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (3). Last acquisition attempt exception:
java.sql.SQLException: An SQLException was provoked by the following failure: com.mchange.v2.resourcepool.ResourcePoolException: Attempted to use a closed or broken resource pool
Those exceptions showed up more than once. After some search in the internet I couldn't find a unique solution, everyone seems to have found his own way to solve the problem. And so did I.

The problem was those 3 drop downs after the loggin procedure. This 3 queries required 3 connections, one for each. At this time, the datasource was null and because the server calls in GWT are asynchronous, for every call was the datasource null... So, there was a tripple c3p0 initialization and this created the problems.

I have created a project in eclipse with the google plugin that should run on the app engine. Therefore it uses the datanucleus framework and JDO. Because of eclipse everytime you change a class in the build path, the datanucleus Enhancer runs and enhances the classes that should be persistent (capable or award).

I wrote a test case to test some code using the annotations @RunWith and @Test, plus some more for the spring configuration (@ContextConfiguration and @Autowired). When I saved the first version of the test (it compiled successfully at last) I noticed that on the console there was a warning from datanucleus enhancher:

11 Ιουν 2009 12:49:02 μμ org.datanucleus.metadata.annotations.AnnotationManagerImpl getMetaDataForClass
WARNING: Class "the class name" has annotations but there is no registered AnnotationReader. Please check your CLASSPATH and the annotations in the class for validity.

It seems that JPOX (the base of datanucleus) supports plugins for annotations through an AnnotationReader interface. The desirable solution for my case were to tell datanucleus to ignore the test class through (for example) an annotation.

This post applies to eclipse IDE.

If you have an interface (say Test) with a method declared (say testMethod) and you create a new class that implements this interface, there will be an error, that the class you declared must implement the methods defined in the interface. There is also a quick fix available that implements this methods in respect to a code template. If you choose the quick fix the result will be like:

@Override
public String testMethod() {
// TODO Auto-generated method stub
return null;
}

Say, you are working in a team (this is the default situation for a company), and you forget to implement the method. The result will be in the best case will be a null pointer exception somewhere in the code, but surely not in the method above. The return null is not the best solution for the default implementation. Even worse, the method could return an int value, then the default return value from the template would be 0, so no error is visible at runtime...

It would be better if the code would show exactly where the problem is (that means in the method testMethod) and even better, who is responsibly for this error. Both tasks are covered with the following code:

@Override
public String testMethod() {
// TODO Auto-generated method stub
throw new IllegalStateException("User X didn't do his work!");
}

This piece of code cures both problems. An exception is thrown, so everyone knows where the error is, and even better, they know who is responsible for this.

To change the template in eclipse go to eclipse preferences Java > Code Style > Code Templates
There in the tree select Code > Method body.
Press Edit... and change the pattern in

@Override
// ${todo} Auto-generated method stub
throw new IllegalStateException("${user} didn't do his work!");

Press OK and OK again and test the pattern.