To put it in a simple way, I suspect there is a bug in the way rollbacks are implemented
First of all, we are not building a web app, but a normal application. Hence we need to have what we could call transcient objects.
Our first try was to assign one Session by user, and have this Session last all the application running time - ie we are NOT in the one Session per Transaction paradigm. I insist on this point, because I know people are going to answer that (and it's also said in te doc) a Session should be closed as soon as possible after a rollback. This is simply not what I'm trying to do here. It might be a school case, but still there is a real problem here.
s = sf.openSession();
for (int comptCommandeClient = 0; comptCommandeClient < 8; comptCommandeClient++) {
try {
System.out.println ("SESSION.CONNECTION = " + s.connection());
Transaction t = s.beginTransaction ();
tpCommande comm = new tpCommande ();
comm.setLibelle("temporaire_" + comptClient);
if ((comptCommandeClient % 2) == 0) {
t.commit ();
} else {
t.rollback ();
System.out.println ("### ROLLBACK !!!");
}
System.out.println ("Etat du commit : " + t.wasCommitted());
System.out.println ("Etat du rollback : " + t.wasRolledBack());
} catch (Exception cce) {
cce.printStackTrace();
}
s.close ();
The database is Postgres 7.4, and there is a c3p0 pool (but the problem also exists without pooling)
After running this code, the first seven records are written in the DB, and only the last one was really ignored, when all the odds should have been rolled back.
As I understand it, after making a whole day of diff
|