[Springframework-developer] Batch processing with hibernate

[Meyer, S. <S....@S2...>]

(This is concerning an earlier entry by myself. I am not sure I chose
the subject well.)

The feature that I miss about the HibernateTransactionmanager is
Save-Points. I understand, that hibernate does not support partial or
even complete rollbacks. I think that in the specific case, where you
know all the entites associated wih the current session, you can
rollback by clearing the session and then refreshing all those entities.
In case of rollbacks to savepoints this means, that the db must return
the changes already flushed unto that savepoint. I am not sure if this a
requirement all dbs fullfill in all isolation levels but I suppose so.
Here is the implementation of setting a savepoint and rolling back to
it:

savePoint setSavepoint() {
	session.flush();//synchronize session state with db=20
	return session.connection.setSavepoint();
}

rollbackToSavepoint(Savepoint s) {
	session.clear();//discard all changes
	session.connection().rollback(s);
	for (...){//iteration over all entities
		session.refresh(entity);//reintialize session state from
db
	}
}

My application of this is a batch processing template with the folowing
callback:

Interface BatchProcessingCallback<T> {
	T selectEntity();
	void processEntity(T entity);
	void handleException(T entity);
}

The idea is to be able to select a single entity "for update" and
process it and then select the next and so on. If the processing of one
entity fails it can still be altered so that it won't be selected by the
processor again - making the processor fail over and over again while
other entites are not selected until manual intervention.

The batch processor processes entities until none is returned by the
callback.selectEntity(). The batch processor first calls selectEntity(),
then sets a savepoint (=3Dstarts an inner transaction). If an exception
occurs during processing or the transaction is set to rollback only, the
batchprocessor will rollback to that savepoint (rollback the inner
transaction) and call handleException(). At that point the client code
is responsible for marking the entity that was not processable as
corrupt, so it won't be picked up again.=20