Question

I have a method that transfers data from one database to another and in the process creates new tables in the target database. The method is part of a stateless EJB (Java EE 6, GF 3.1) so the container, by default, starts a distributed transaction when the method is called.

The data transfer process essentially runs as two separate steps 1. read from the source database 2. write to the target database. If the read step fails then I don’t want the write step to happen but if the write step fails and the read has been committed already I don’t really care – I’ll just throw the data away.

Initially I hit the problem that my data sources weren’t XADataSource’s so the container complained about that. I then converted them to XADataSource’s but it still failed because the write process (which is into a MySQL database) contains create table statements which cause an implicit commit and you can’t do that in a distributed transaction.

The solution I’ve finally come to is to mark transfer method as TransactionAttributeType.NOT_SUPPORTED and then place the read and write process into their own methods which are called by the parent transfer method.

My question though is this: do the read and write methods run inside their own transactions or does the NOT_SUPPORTED propagate to them? My guess is that they have an implicit TransactionAttributeType.REQUIRED and so will start their own transaction but I’m not sure and I think it’s important they are running inside a transaction.

Is this the best solution to this problem?

Answer 1

The bigger question for separating the read and write steps is whether or not the write step should still be performed if some other thread/process is mutating the data that was obtained from the read step. In other words, are you sure that the read and write should not be in the same transaction? Perhaps you have some external guarantee that there won’t be problems writing the data separately.

How are the read and write methods called? If they’re called as local methods, then the NOT_SUPPORTED will propagate. If they’re called through a session bean proxy object, then the default REQUIRED will apply:

@Stateless
@Local(MyIntf.class)
public class MyBean {
    @EJB
    private MyIntf ivMyBean; // Self-injection

    @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
    public void method() {
        // Use the injected proxy rather than "this.read()" to ensure that the
        // default REQUIRED transaction attribute is used for the DB operations.
        MyResults results = ivMyBean.read();
        ivMyBean.write(results);
    }

    public MyResults read() { ... }
    public void write(MyResults results) { ... }
}

It seems somewhat questionable that you have to create tables based on the read data. Is there really no way to do that as a separate operation? I would suggest an outer REQUIRED method that does the read operation, then calls a NOT_SUPPORTED method to create tables, and finally does the write operation in the same transaction as the read, which was temporarily suspended while the NOT_SUPPORTED method was running.