I must have the ability to verify if each unit of labor is completed in its very own transaction, or included in just one global transaction.

I've got a method (defined using spring and hibernate), that is from the form:

private void updateUser() {
    updateSomething();
    updateSomethingElse();
}

This really is known as from two places, the web site whenever a user logs in along with a batch job which runs daily. For that web server context, it'll run having a transaction produced through the web server. For that batch job, it has to have one transaction for every user, to ensure that if something fails throughout this process, the transaction is folded back. Therefore we have two techniques:

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void updateUserCreateNewTransaction() {
    updateUser();
}

@Transactional(propagation=Propagation.REQUIRED)
public void updateUserWithExistingTransaction() {
    updateUser();
}

updateUserCreateNewTransaction() is known as in the batch job, and updateUserWithExistingTransaction() on the internet server context.

This works. However, it is crucial this behavior (from the batch) 't be transformed, so If only to produce a test that tests this behavior. If at all possible, I must do that without altering the code.

So a few of the options available to me are:

  1. Count the transactions opened up within the database throughout the run from the batch job.

  2. Alter the data in certain sublte way to ensure that a minumum of one user update fails, within the updateSomethingElse() method, and appearance the updateSomething() for your user hasn't occurred.

  3. Code review.

1 is an extremely database dependent method, and just how will i guarantee that hibernate will not produce a transaction anyway?. 2 appears better, but is extremely complex to setup. 3 isn't practical because we will have to do one for each release.

So, does anybody possess a method which may enable me to check this code, ideally via a system test or integration test?

I'd attempt to setup an evaluation inside a unit test harness utilizing an in memory HSQLDB and EasyMock (as well as other mocking framework).

You can then possess the updateSomething() method really email the HSQL database but make use of the mock framework to mock the updateSomethingElse() method and throw a RuntimeException from that method. When that's done you can execute a query from the HSQLDB to ensure the updateSomething() stuff was folded back.

It may need some plumbing to create the HSQLDB and transaction manager however when that's done you've got a test without exterior dependencies that may be re-run if you like.

Another factor you should do is configure logging output for Hibernate's transactions:

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html#configuration-logging

If one makes a log4j category for org.hibernate.transaction with trace log leve, it will tell exactly what Hibernate does transaction-smart throughout one test.