DataForm.onSubmit field/transaction errors

[Rob McClay]

I'm using DataBinder 0.7.

In DataForm.onSubmit, if a commit fails, shouldn't the transaction be rolled back? When for example I receive an error like this:

org.postgresql.util.PSQLException: ERROR: value too long for type character varying(255)

And I hit back, adjust the problem, and re-submit, I get this error:

org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block

Thanks. Databinder is a great way to learn wicket & hibernate.

[Nathan]

What happens if you catch the exc and call session.getTransaction().rollback(), does that fix it? I thought Hibernate was rolling back uncommitted transactions itself on session.close(), but it could be that MySQL glosses over the problem.

[Rob McClay]

Yes that fixes the problem. It could be a connection pool issue or a difference between the postgres / mysql driver, or a difference in how postgres handles transactions. When the connection is returned to the pool, it can be left in a bad state, and subsequent requests to that connection will fail. In a transaction, in postgres, rolling back the connection on an exception works like a charm.

[Nathan]

Good, thanks for reporting this. At a minimum I'll add a rollback to DataForm.onSubmit(), or maybe I'll put it in a RequestCycle.onRuntimeException() override (which is what it's there for, I think).

Would you mind also checking what happens with postgres if you don't call commit() at all, but do make changes to an object? (This leaves the database unchanged in MySQL.) If that doesn't lead to any problems, then I'll probably put the rollback in DataForm only, and not take any action based only on uncaught exceptions. I'd like to leave commit and rollback in the hands of the user, if possible.

[Rob McClay]

Preliminary testing shows that removing the commit causes it not to commit. My concern would be that if you're in a transaction it should probably be committed / rolled back. As when an exception was thrown and it wasn't rolled back, the connection was released back to the pool in a strange state which caused subsequent access to that connection to fail. It didn't behave the same way for commits though but the concern might be that you could get a connection that is already in a transaction and if it is then committed, maybe the other updates would be committed as well? My quick test of that scenario worked without a hitch but I may not have used the same connection.

Adding the rollback to DataForm.onSubmit seems like a good plan, close to the commit in proximity.

[Rob McClay]

Maybe this?

try {
session.getTransaction().commit();
} catch(RuntimeException e) {
session.getTransaction().rollback();
throw e;
}

[Nathan]

Did some reading:
http://www.hibernate.org/hib_docs/v3/reference/en/html/transactions.html#transactions-demarcation-nonmanaged

Hibernate recommends catching these exceptions "at the top," it turns out, then immediately rolling back and closing the session. That's pretty easy to do thanks to onRuntimeException(), so I've added that to DataRequestCycle in 0.9-SNAPSHOT. If an uncaught exception occurs in onSubmit's commit operation, or anywhere else, it will roll back the transaction, and close and null out the session.

You can try it out in the snapshot if you want, or catch the exception at the source for now. The only problem is you can't null out the session pointer that's in DataRequestCycle, which would cause an exc later on if you have other models that try to load themselves with the closed session.

[Rob McClay]

Another thing, in DataRequestCycle.onEndRequest, I think the transaction needs to be either committed or rolled back if the transaction is started. If it isn't, my postgres process still says "idle in transaction", even after session.close() is called. Eg., I don't think session.close() rolls back an uncommitted transaction. Thoughts? Again, using postgres 8.

[Nathan]

Ok, we can do that too. Just released a snapshot that rolls back any uncommitted transaction. Here's the code if you want to take a look:

http://databinder.net/wsvn/Databinder/databinder/trunk/src/main/java/net/databinder/DataRequestCycle.java?op=file

And thanks so much for reporting these. It's too bad MySQL is so forgiving... it's like writing HTML for IE.

[Rob McClay]

I'll verify that one Nathan -- it could be that the connection pool that I was using didn't rollback an uncommitted transaction prior to close, and I have recently switched connection pools. I'll take a look and report the results. It may be unnecessary. Thanks.

[Nathan]

Aha. c3p0 does roll back automatically, but apparently the standard behavior for that situation is not defined. It's probably better if we do the rollback in Databinder so we can work with more pools. And I don't think it's costing us anything.