Make I.T. Simple

Sorting results when using TopLink ObjectLevelReadQuery conformresultsinunitofwork()

2010-04-26T14:40:00.000-04:00

This article explains odd TopLink behaviors when sorting query results that includes both in memory as well as persistent data from database.

As you know, conformresultsinunitofwork enables the query to merge results from database with those in-memory objects. For instance, the following data exist in EMPLOYEE table:
name                type
-----              ------
employee 1    contractor
employee 2    contractor

And in the session of the same transaction, there are newly created Employee objects "emplyee 3" and "emplyee 4", also contractors. If we want to find all the contractor employees including the ones in the memory, we should use conformresultsinunitofwork(), and the query result will be:
"employee 3"
"employee 2"
"employee 1"
"employee 4"

If the query result is sorted by name, like
ExpressionBuilder builder = new ExpressionBuilder();
query.addOrdering(builder.get("name").ascending());

You would expect that the result be:
"employee 1"
"employee 2"
"employee 3"
"employee 4"

You are wrong! The end result is not actually sorted!!! TopLink will actually just send the query to Oracle
server, which executes it and sorts the result by name, then TopLink will again add the in-memory objects on the top of collection returned from database:
"employee 3" (in-memory)
"employee 4" (in-memory)
"employee 1" (from DB)
"employee 2" (from DB)

Note that the in memory objects are not sorted at all, but the ones from DB are. The reason it behaves like this, is that Oracle server has no idea about the newly created objects, though I believe TopLink can be improved by not sending the "order by" to Oracle, instead just doing it in the session before returning the combined result to your application code. Anyway, if you run into such issue, just implement the query without sorting, and once you get the result, you then sort results in memory using Java. Just remember not to sort it twice, once in Oracle server and once in your Java code.

Functional Junit Test - Part 3 - Hot Swapping Using JDK Proxy

2010-04-02T11:48:00.000-04:00

Have you ever wished that you could replace an instance with another stub during runtime? Spring framework provides an TargetSource implementation - HotSwappableTargetSource that facilitates such hot swapping at runtime. If for whatever reason, you are not using Spring framework, here is an alternative - JDK Proxy.

The following example shows how to implement JDK Proxy to swap the DAO implementation at runtime. The idea applies to any implementation as long as there is an interface backing it up (as you are aware that JDK proxy only works for interfaces).

Please note the code below only demonstrates the concept and is not working code.

Create an InvocationHandler:

public class Swapper implements java.lang.reflect.InvocationHandler {

        private Object impl;

        private Object realDAO;

        private Object stubDAO;

        boolean useRealDAO;

        
...

       public Object invoke(Object proxy, Method method, Object[] args) {

                  //the logic to choose real or stub depends on your  own system. e.g. you may use a flag

                  //to determine which object to return. 

                  if (useRealDAO) impl = realDAO;

                  else impl=stubDAO;

                  return method.invoke(impl, args);

}

}

When the DAO is created, it has to use proxy:

Swapper swapper= new Swapper(readDAO, stubDAO);

            Object proxy = Proxy.newProxyInstance(stubDAO.getClass().getClassLoader(),

                    new Class[] { theInterface }, swapper);

where "theInterface" is the interface name for real and stub DAO.

In your business service class:

SomeServiceClass

{

    EmployeeDAO employeeDAO= (use the above created proxy)
    void loadEmployeeDetails(Employee employee)
   {
      dao.loadDetails();   

    }
}

To swap at runtime:

((Swapper)employeeDAO).setUseRealDAO(true);

service.loadEmployeeDetails(employee); //loads detail through the real DAO

((Swapper)employeeDAO).setUseRealDAO(false);

service.loadEmployeeDetails(employee); //loads detail through the stub DAO

Please note that, in real world, the DAO will most like be created by a factory class or a container so that the code creating the proxy doesn't need to duplicate.

This shows the simple idea:

Service
    |

Proxy

/    \
real stub

This technique will also support dynamic reconfiguration of any Java application.

Developing a Spring Framework MVC application step-by-step

2010-03-30T16:45:00.000-04:00

Recommending the following tutorials on Spring MVC:

#2 is same as #1 except for the use NetBeans.

Some thoughts:

The way they set up the message bundle is confusing: in the section "Add the Message Bundle", it says to add message.properties into WEB-INF/classes folder. Well, of course, it works that way. But in a real project, you won't be adding stuff in the classes directory. It should be deployed there. So just put the message.properties in your source package or a resource folder, and let the build script copy into the classes directory.
Spring MVC supports 4 kinds of handler mapping:

BeanNameUrlHandlerMapping
SimpleUrlHandlerMapping
CommonsPathMapHandlerMapping
ControllerClassNameHandlerMapping

By default, if no handler mapping is registered in the application context file, Spring
Dispatcher Servlet will use #1, i.e. BeanNameURLHandlerMapping. The above 2 tutorials are actually using the default BeanNameUrlHandlerMapping created by the dispatcher servlet.

Microfocus Cobol Calling Remote EJB Services

2010-03-25T17:00:00.000-04:00

I'm working on a Loans project for which we are exploring an option in order to address some critical system issues. The option requires a Cobol program running in a server (within a nightly flow) to call a EJB service running in another Websphere server (this will physically reside in a different server than the Cobol one). How interesting this is going to be? It sounds doable, but I don't know anything about cobol and will post new stuff here to tell the interesting story as the project moves on. Stay tuned!

Repeatable read only integration test

2010-03-22T17:32:00.000-04:00

Have you ever wished that, changes are not committed to the database so that your test will be repeatable when you are testing from a typical desktop application? This posting shares some of my experience.

Settings: my local environment is a 2-tier Java Swing desktop application using TopLink against Oracle database.

Create a connection proxy that implements java.lang.reflect.InvocationHandler, in which, the invoke() method should check the value of method.getName() and trap the call here, e.g. if the method name is "commit", you want to return null so that the driver won't commit the changes. Otherwise, let it go by returning method.invoke(connection, args).

Create a read only driver (implements java.sql.Driver interface), which should implement "connect()" method. The method should connect to the DB using oracle.jdbc.driver.OracleDriver class, and should return an instance of the above connection proxy.

In your test driver, call java.sql.DriverManager.registerDriver() to register your driver proxy and launch your desktop application as you normally do.

Running JPA examples in Java SE (non-Managed) and EE (managed) environment

2010-03-18T15:52:00.000-04:00

This article explains how to run JPA programs in Java SE (non-Managed) and EE (managed) environment
https://glassfish.dev.java.net/javaee5/persistence/persistence-example.html#Using_in_Java_SE

The Java Persistence API - A Simpler Programming Model for Entity Persistence

2010-03-17T17:15:00.000-04:00

Recommending a great article, describing the enhancement in EJB 3.0 comparing to EJB 2.1:
http://java.sun.com/developer/technicalArticles/J2EE/jpa/

The only thing I don't like about the annotation, e.g. look at the way the many-to-many relationship is implemented. It's NOT intuitive to read. It would have been better if we could do something like this:


    @JoinTable(CUSTOMERBEANSUBSCRIPTIONBEAN#CUST_FK->CUSTOMERBEAN#ID,
                        CUSTOMERBEANSUBSCRIPTIONBEAN#TITLE_FK->SUBSCRIPTIONBEAN#ID)

Standardizing Java Persistence with the EJB3 Java Persistence API - O'Reilly Media

2010-03-16T17:34:00.000-04:00

Standardizing Java Persistence with the EJB3 Java Persistence API - O'Reilly Media

Posted using ShareThis

Coming from TopLink/Hibernate background, I can see how simple JPA is, comparing to TopLink or Hibernate (the non-JPA implementation). Note that,as of 2009 projects like Hibernate and Open-Source Version TopLink Essentials have become implementations of the Java Persistence API.

Mapping is much cleaner. Named queries are better implemented! You can now forget all the amender classes/methods:) Annotations rock. Even better, JPA provides a consistent persistence layer regardless of the implementation details (e.g. TopLink essentials or Hibernate). God bless!

Functional Junit Test - Part 2 - Making newly created session objects available for query

2010-03-11T17:11:00.000-05:00

Making new session objects available for Object Level Query

Sometimes you may need to create data in the TopLink session to support your test scenarios. To make those newly created objects available for object level queries down the road in your execution patch, you need to do the following:

register the new object into the session using UnitOfWork.registerNewObject()
call alwaysConformResultsInUnitOfWork.

Then, the new object (though not committed to the database) will be seen by object level queries, e.g. when you call oracle.toplink.sessions.Session.readAllObjects(entityClass, expression), the new object, if satisfying the expression, will be included in the returned collection.

Remember that, if you read Part 1 of this series, the new object will not be saved into database. The changes are being rolled back for each test case as described in Part 1.

Making new session objects available for non-Object Level Query

If there are non-object level queries in your application, e.g. Named Query, and you want to create test data for the query, then do the following:

register the new object into the session using UnitOfWork.registerNewObject()
call UnitOfWork.writeChanges().

There is a limitation: you can only call writeChanges() once per session.

Functional Junit Test - Part 1 - Database Rollback

2010-03-11T15:43:00.000-05:00

Overview

Unit tests should be isolated and repeatable. Many are using mock frameworks like JMock, EasyMock etc. And those test cases should not interact with other layers (e.g. network services or database, etc).

This post is not going to talk about those mocking frameworks. Instead, I'll share with you some of my experience working on integration test: functional Junit test cases that interact with database server.

This is not a place to debate whether dependencies should be mocked out or not.

Our development settings are Eclipse + TopLink + Oracle and test cases run in a local environment (not JTA environment). I'll publish a series of posts in my blog about functional Junit test.

Database Rollback

This 1st post is about database rollback, which makes Junit test cases repeatable. Implementation is very simple. In the tearDown(), you just need to call

oracle.toplink.sessions.UnitOfWork.release().
oracle.toplink.sessions.Session.release().

with the assumption that the TopLink session and unit of work is being created somewhere in your application code, e.g. when registering a new object into TopLink or when retrieving data from the database. By calling the above two methods, you are basically rolling back all the changes made by your test cases. In my projects, we used a base test case to host the rollback logic.

Debug Maven project in Eclipse

2010-03-08T13:39:00.000-05:00

Recently I read the instruction about debugging Maven project in Eclipse http://docs.codehaus.org/display/MAVENUSER/Dealing+with+Eclipse-based+IDE

It mentioned that you need to create a Java project (e.g. "Maven Debug") in order to attach the debugger. I found this unnecessary and you don't have to create such additional project. Here is how:

Click "Run" -> "External Tools" -> "External Tools Configurations..."
Create new configuration.

Where maven_exe points to your Maven installation folder. Click "run" and you should see in the console that it launched the debugger, listening to port 8000.

Now go to "Run"-> "Debug Configurations..." and create a new "Remote Java Application":

On "connect" tab, set project to your Eclipse project you want to debug. Host = localhost, port = 8000.
On "Source" tab, add your Eclipse project as the source lookup path
Finally, click "debug" and it will stop at your breakpoints.

Happy debugging!

(I used Eclipse 3.4, Maven 2.2.1 and Maven Integration for Eclipse)