users@glassfish.java.net

TopLink Essentials cannot handle large transactions, makes JVM run out of memory.

From: Witold Szczerba <pljosh.mail_at_gmail.com>
Date: Sun, 9 Sep 2007 20:18:48 +0200

Hi there,
I have problem, looks like there is something wrong with TopLink
Essentials (tested with GFv2RC4).
It cannot handle large transactions, because it uses more and more
memory and eventually makes JVM crash because of OutOfMemory
exception.

Here is a simple case to show what the problem is:

@Stateless
public class PersonServiceBean implements PersonServiceRemote {

    @PersistenceContext
    private EntityManager em;

    public PersonServiceBean() {
    }
    public void go() {
        for (long i=10000000; i>00; i--) {
            Person person = new Person();
            person.setId(i);
            person.setFirstName("firstName_"+i);
            person.setLastName("lastName_"+i);
            em.persist(person);
            if (i%10000 == 0) {
                System.out.format("%,d%n",i);
                em.flush();
                em.clear();
            }
            if (i==1) throw new RuntimeException();
        }
    }
}

The method "go" will never finish, with 512MB of RAM for Glassfish,
the JVM will crash after processing 1,000,000 records, but don't
forget it is just a test case, Person entity contains only two string
properties and nothing more. I know one can split one big transaction
into smaller ones (for example one tx per 10,000 records, but what if
I want all or nothing?)

I know it is very rare to use so big transactions, but here is an
example, where large transactions are required: in the company I work,
me and co-workers, we are developing new application using JavaEE that
is going to replace an old one written in M$Access. From the very
beginning, we had to develop parallel application that makes
conversion of data from legacy system (using ODBC-JDBC bridge) into
new structures. Because, in our new JavaEE application we use JPA, we
are using it in the module that transfers data from Access (that
really helps with refactoring, we can see problems with transfer
project immediately when we change/enhance entity classes).

After many days of "fighting" with TopLink (it was somewhere at the
beginning of this year, in those time I though it was a memory leak, I
posted many emails here), we switched to Hibernate (only in the
transfer project) and it works, I mean this is not a problem for
Hibernate to perform transaction of any size. It just pumps data into
database, uses almost no extra memory.

Can this be considered as a bug? Should I fill an issue?

Regards,
Witold Szczerba