Spring Roo project as batch job without transactions

Question

I have a Roo project that works "fine" with transactions, but each .merge() or .persist() takes longer and longer time, so that what should've taken 10ms takes 5000ms towards the end of the transaction. Luckily, my changes are individually idempotent, so I don't really need a transaction.

But when I throw out transaction handling I run into the classic "The context has been closed" when I do myObject.merge()

The job I'm running is from the command line as a batch, so here is what I usually do:

public static void main(final String[] args) {
    context = new ClassPathXmlApplicationContext("META-INF/spring/applicationContext.xml");
    JpaTransactionManager txMgr = (JpaTransactionManager) context.getBean("transactionManager");
    TransactionTemplate txTemplate = new TransactionTemplate(txMgr);
    txTemplate.execute(new TransactionCallback() { @SuppressWarnings("finally")
    public Object doInTransaction(TransactionStatus txStatus) {
    try {
        ImportUnitFromDisk importer = new ImportUnitFromDisk();
        int status = importer.run(args[0]);
        System.out.println("Import data complete status: " + status);
    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        return null;
    }
    }});

    System.out.println("All done!");
    System.exit(0);
}

But what I really want to do is something like this:

public static void main(final String[] args) {
    ImportUnitFromDisk importer = new ImportUnitFromDisk();
    int status = importer.run(args[0]);
    System.out.println("Import data complete status: " + status);
    System.out.println("All done!");
    System.exit(0);
}

What can I do to allow me to persist() and merge() without using transactions, given that the entities are generated with Spring Roo (using OpenJPA and MySQL)?

Cheers

Nik

Answer 1

Even if your changes are idempotent, you still will need transaction.

As far as performance is concerned.

1. How tightly coupled is your entity objects. (For instance if all table fk refernces are migrated to entity relationship, then its pretty tightly coupled)?

2. May be you should remove some unwanted bidirectional relationships.

3. Identify master tables and remove entities mapping to master records.

4. What is your cascade options? Check if you have cascade all options everywhere.

For me it looks the Entity map is far too tightly coupled .(Everyone knows someone who has ...) and the cascade options kick off merging the whole object graph. (log your jpa sql, that can validate my assumption)